Federal Communications Commission FCC 08-99 Before the Federal Communications Commission Washington, D.C. 20554 In the Matter of The Commercial Mobile Alert System ) ) ) ) ) PS Docket No. 07-287 FIRST REPORT AND ORDER Adopted: April 9, 2008 Released: April 9, 2008 By the Commission: Chairman Martin, and Commissioners Copps, Adelstein, Tate and McDowell issuing separate statements. TABLE OF CONTENTS Heading Paragraph # I. INTRODUCTION.....................................................................................................................1 II. BACKGROUND.......................................................................................................................5 III. DISCUSSION............................................................................................................................7 A. Consideration of the CMSAAC Recommendations............................................................8 B. CMAS Architecture and CMS Provider Functions ...........................................................10 C. General CMAS Requirements...........................................................................................25 1. Scope and Definition of CMAS Alerts........................................................................26 a. Presidential Alerts .................................................................................................28 b. Imminent Threat Alerts .........................................................................................29 c. Child Abduction Emergency/AMBER Alerts .......................................................31 2. Technologically Neutral Alert System ........................................................................33 3. CMAS Message Elements and Capabilities ................................................................41 a. Required Alert Message Elements ........................................................................41 b. CMAS Generation of Free Text Alert Messages...................................................44 4. Geo-targeting CMAS Alerts........................................................................................48 5. Meeting the Needs of Users, Including Individuals with Disabilities and the Elderly .........................................................................................................................57 6. Output Mode/Display ..................................................................................................68 7. Message Retransmission .............................................................................................70 8. Multi-Language CMAS Alerting.................................................................................71 9. Roaming ......................................................................................................................78 10. Preemption of Calls in Progress ..................................................................................80 D. Service Profiles..................................................................................................................81 E. Security for CMAS Alerts .................................................................................................87 F. CMAS Reliability and Performance..................................................................................90 Federal Communications Commission FCC 08-99 2 G. Timeline for Implementation of Technical Requirements, Standards and Protocols. ...........................................................................................................................92 IV. PROCEDURAL MATTERS...................................................................................................96 A. Final Regulatory Flexibility Act Analysis.........................................................................96 B. Final Paperwork Reduction Act of 1995 Analysis ............................................................97 C. Congressional Review Act Analysis .................................................................................98 D. Alternative Formats ...........................................................................................................99 V. ORDERING CLAUSES........................................................................................................100 APPENDIX A - List Of Commenters APPENDIX B - Final Regulatory Flexibility Analysis APPENDIX C - Final Rules .............................................................................................................. I. INTRODUCTION 1. This Commercial Mobile Alert System First Report and Order (CMAS First Report and Order) represents our next step in establishing a Commercial Mobile Alert System (CMAS), under which Commercial Mobile Service (CMS) providers1 may elect to transmit emergency alerts to the public. We take this step in compliance with section 602(a) of the WARN Act,2 which requires the Commission to adopt “relevant technical standards, protocols, procedures, and other technical requirements” based on the recommendations of the Commercial Mobile Service Alert Advisory Committee (CMSAAC) “necessary to enable commercial mobile service alerting capability for commercial mobile service providers that voluntarily elect to transmit emergency alerts.” 2. In this CMAS First Report and Order, we adopt rules necessary to enable CMS alerting capability for CMS providers who elect to transmit emergency alerts to their subscribers. Specifically, we adopt the architecture for the CMAS proposed by the CMSAAC and conclude that a Federal Government entity should aggregate, authenticate, and transmit alerts to the CMS providers. In addition, we adopt technologically neutral rules governing: · CMS provider-controlled elements within the CMAS architecture (e.g., the CMS Provider Gateway, CMS Provider infrastructure and mobile devices); · Emergency alert formatting, classes, and elements: Participating CMS Providers must transmit three classes of alerts - Presidential, Imminent Threat, and AMBER alerts; 1 For purposes of section 602 of the Warning, Alert and Response Network (WARN) Act, Congress specifically defined “commercial mobile service” as that found in section 332(d)(1) of the Communications Act of 1934, as amended, 47 U.S.C. § 332(d)(1) (the term “commercial mobile service” means any mobile service that is provided for profit and makes interconnected service available to the public or to such classes of eligible users as to be effectively available to a substantial portion of the public, as specified by regulation by the Commission). Warning, Alert, and Response Network Act, Title VI of the Security and Accountability for Every Port Act of 2006, Pub. L. No. 109-347, 120 Stat. 1884, (2006), Titles I through III of the Communications Act of 1934, as amended, and Executive Order 13407 of June 26, 2006, Public Alert and Warning System, 71 Fed. Reg. 36975 (June 26, 2006) (WARN Act), § 602(b)(1)(A) (Executive Order 13407). 2 WARN Act, § 602(a). Federal Communications Commission FCC 08-99 3 · Geographic targeting (geo-targeting): Participating CMS Providers generally are required to target alerts at the county-level as recommended by the CMSAAC; · Accessibility for people with disabilities and the elderly: Participating CMS Providers must include an audio attention signal and vibration cadence on CMAS-capable handsets; · Multi-language Alerting: Participating CMS Providers will not be required at this time to transmit alerts in languages other than English; · Availability of CMAS alerts while roaming: Subscribers receiving services pursuant to a roaming agreement will receive alert messages on the roamed upon network if the operator of the roamed upon network is a Participating CMS provider and the subscriber's mobile device is configured for and technically capable of receiving alert messages from the roamed upon network; · Preemption of calls in progress: CMAS alerts may not preempt a voice or data session in progress; · Initial implementation: Participating CMS Providers must comply with these rules no later than 10 months from the date the FCC announces the selection of a Federal Government entity to perform the Alert Aggregator and Alert Gateway functions required to implement the CMAS. 3. In adopting these rules today, we take a significant step towards implementing one of our highest priorities – to ensure that all Americans have the capability to receive timely and accurate alerts, warnings and critical information regarding disasters and other emergencies irrespective of what communications technologies they use. As we have learned from disasters such as the 2005 hurricanes, such a capability is essential to enable Americans to take appropriate action to protect their families and themselves from loss of life or serious injury. This CMAS First Report and Order also is consistent with our obligation under Executive Order 134073 to “adopt rules to ensure that communications systems have the capacity to transmit alerts and warnings to the public as part of the public alert and warning system,”4 and our mandate under the Communications Act to promote the safety of life and property through the use of wire and radio communication.5 4. This CMAS First Report and Order is the latest step of our ongoing drive to enhance the reliability, resiliency, and security of emergency alerts to the public by requiring that alerts be distributed over diverse communications platforms. In the 2005 EAS First Report and Order, we expanded the scope of the Emergency Alert System (EAS) from analog television and radio to include participation by digital television broadcasters, digital cable television providers, digital broadcast radio, Digital Audio Radio Service (DARS), and Direct Broadcast Satellite 3 Public Alert and Warning System, Exec. Order No. 13407, 71 Fed. Reg. 36975 (Jun. 26, 2006) (Executive Order 13407). In Executive Order 13407, the President noted that it was the “policy of the United States to have an effective, reliable, integrated, flexible, and comprehensive system to alert and warn the American people in situations of war, terrorist attack, natural disaster, or other hazards to public safety and well-being . . .,” and established certain obligations in this regard for the Department of Homeland Security, the National Oceanic & Atmospheric Administration (NOAA), and the FCC. 4 Executive Order 13407, § 3(b)(iii). 5 See 47 U.S.C. § 151. Federal Communications Commission FCC 08-99 4 (DBS) systems.6 As we noted in the Further Notice of Proposed Rulemaking that accompanied the EAS First Report and Order, wireless services are becoming equal to television and radio as an avenue to reach the American public quickly and efficiently.7 As of June 2007, approximately 243 million Americans subscribed to wireless services.8 Wireless service has progressed beyond voice communications and now provides subscribers with access to a wide range of information critical to their personal and business affairs. In times of emergency, Americans increasingly rely on wireless telecommunications services and devices to receive and retrieve critical, time-sensitive information. A comprehensive wireless mobile alerting system would have the ability to alert people on the go in a short timeframe, even where they do not have access to broadcast radio or television or other sources of emergency information. Providing critical alert information via wireless devices will ultimately help the public avoid danger or respond more quickly in the face of crisis, and thereby save lives and property. II. BACKGROUND 5. On October 13, 2006, the President signed the Security and Accountability For Every Port (SAFE Port) Act into law.9 Title VI of the SAFE Port Act, the Warning Alert and Response Network (WARN) Act, establishes a process for the creation of the CMAS whereby CMS providers may elect to transmit emergency alerts to their subscribers. The WARN Act requires that we undertake a series of actions to accomplish that goal, including requiring the Commission, by December 12, 2006 (within 60 days of enactment), to establish and convene an advisory committee to recommend system critical protocols and technical capabilities for the CMAS.10 Accordingly, we formed the CMSAAC, which had its first meeting on December 12, 2006.11 The WARN Act further required the CMSAAC to submit its recommendations to the Commission by October 12, 2007 (one year after enactment).12 The CMSAAC submitted its report to us on that date.13 6 See, e.g., Review of the Emergency Alert System, EB Docket No. 04-296, First Report and Order, 20 FCC Rcd 18625 (2005) (EAS First Report and Order and Further Notice) 7 Id at 18625, 18653. 8 Cellular Telecommunications & Internet Association, Mid-Year 2007 Top-Line Survey Results, available at http://files.ctia.org/pdf/CTIA_Survey_Mid_Year_2007.pdf (last visited on Mar. 18, 2008). 9 See supra, n.1. 10 WARN Act, § 603(a), (d). 11 As required by the WARN Act, the CMSAAC consisted of representatives from state and local governments, federally recognized Indian tribes, representatives of the communications industry, including both wireless service providers and broadcasters, vendors and manufacturers and national organizations representing people with special needs. The Committee also included other qualified stakeholders such as representatives of the Federal Emergency Management Agency (FEMA) and NOAA. See Notice of Appointment of Members to the Commercial Mobile Service Alert Advisory Committee; Agenda for December 12, 2006 Meeting, Public Notice, 21FCC Rcd 14175 (PSHSB 2006). 12 WARN Act, § 603(c). 13 The CMSAAC held six meetings during which it received progress reports from its internal working groups and presentations from interested parties. On October 3, 2007, the Committee approved a set of recommendations and submitted them on October 12, 2007. In developing its recommendations, the CMSAAC consulted the National Institute of Standards and Technology (NIST), as required by section 603(g) of the WARN Act. Federal Communications Commission FCC 08-99 5 6. Section 602(a) of the WARN Act further requires that, by April 9, 2008 (within 180 days of receipt of the CMSAAC’s recommendations), the Commission complete a proceeding to adopt “relevant technical standards, protocols, procedures and technical requirements” based on recommendations submitted by the CMSAAC, “necessary to enable commercial mobile service alerting capability for commercial mobile service providers that voluntarily elect to transmit emergency alerts.”14 On December 14, 2007, we released the Notice of Proposed Rulemaking15 requesting comment on, among other things, the technical requirements we should adopt to facilitate CMS providers’ voluntary transmission of emergency alerts.16 We specifically invited comment on the CMSAAC’s proposed technical requirements. Comments were due on February 4, 2008, with Reply Comments due on February 19, 2008.17 III. DISCUSSION 7. Consistent with section 602(a) of the WARN Act, today we adopt ‘technical standards, protocols, procedures and other technical requirements . . . necessary to enable commercial mobile service alerting capability for commercial mobile service providers that voluntarily elect to transmit emergency alerts.”18 Specifically, the rules we adopt today address the CMS providers’ functions within the CMAS, including CMS provider-controlled elements within the CMAS architecture, emergency alert formatting, classes and elements, geographic targeting (geo-targeting) and accessibility for people with disabilities and the elderly.19 In most cases, we have adopted rules generally based on the CMSAAC recommendations.20 In such cases, we find that the CMSAAC’s recommendations are supported by the record and that adoption of those recommendations serves the public interest and meets the requirements of the WARN Act. For reasons discussed below, however, in some cases, we have determined that the public interest requires us to adopt requirements that are slightly different than those recommended by the CMSAAC. A. Consideration of the CMSAAC Recommendations 8. Several entities representing the wireless industry generally argue in their comments that the Commission has no authority to adopt technical requirements other than those 14 WARN Act, § 602(a). 15 The Commercial Mobile Alert System, PS Docket No. 07-287, Notice of Proposed Rulemaking, 22 FCC Rcd 21975 (2007) (CMAS NPRM). 16 In the CMAS NPRM, we also sought comment on issues related to other provisions of the WARN Act such as section 602(b) (requiring, among other things, that the Commission establish a mechanism for CMS providers to elect to participate in CMAS); section 602(c) (requiring the Commission to require noncommercial educational (NCE) broadcasters to install equipment to support geographically targeted (geo-targeting) alerts by CMS providers) and section 602(f) (authorizing the Commission to require testing of the CMAS). We will address these provisions of the WARN Act and related issues in subsequent Orders within the deadlines established by the statute. See CMAS NPRM, 22 FCC Rcd at 21976-21978, ¶ 5. 17 A list of the parties commenting on the CMAS NPRM is attached at Appendix A. 18 WARN Act, § 602(a). 19 As required by section 602(a) of the WARN Act, we consulted the NIST in our adoption of technical rules. 20 We note that the overwhelming majority of commenters support our adoption of the CMSAAC recommendations. See, e.g., T-Mobile Comments at 2, 3G America Comments at 11, CTIA Comments at 19, TIA Comments at 10, AT&T Comments at 20, Ericsson, Inc. (Ericsson) Comments at 6, Rural Cellular Association Comments at 1-2. Federal Communications Commission FCC 08-99 6 proposed by the CMSAAC and that those must be adopted “as is.” 21 We disagree. The WARN Act does not require that we adopt the CMSAAC’s recommendations verbatim. Rather, Congress required the Commission to adopt relevant technical requirements “based on recommendations of the CMSAAC.”22 This indicates that while Congress intended that we give appropriate weight to the CMSAAC’s recommendations in our adoption of rules, it did not intend to require the Commission to adopt the CMSAAC’s recommendations wholesale, without any consideration for views expressed by other stakeholders in the proceeding or the need to address other significant policy goals.23 Moreover, adopting the CMSAAC’s recommendations in their entirety, without scrutiny, would result in an abdication of the Commission’s statutory mandate under the Communications Act to act in the public interest. Clearly the WARN Act did not delegate Commission authority under the Communications Act to an advisory committee; on the contrary, the Commission was to conclude a “proceeding” which necessarily implicates notice and an opportunity for public comment, and Commission discretion in adopting appropriate rules and requirements. 9. Commission discretion and flexibility in its adoption of the CMSAAC recommendations is also supported by the policy goal underlying the WARN Act, i.e., the creation of a CMAS in which CMS providers will elect to participate, and which will effectively deliver alerts and warnings to the public. The comments of Ericsson, with which we agree, support Commission discretion by stating that the technical standards and requirements we adopt for the CMAS should account for an evolving technology landscape.24 In order to account for changes in the wireless industry and maintain a technologically neutral approach to emergency alerting, the Commission must be able to apply the CMSAAC’s recommendations to new technologies and services. A reasonable interpretation of the WARN Act, therefore, is that the Commission has the discretion to evaluate the CMAS technical requirements recommended by the CMSAAC. B. CMAS Architecture and CMS Provider Functions 10. In its recommendations, the CMSAAC proposed the following architecture for the CMAS.25 Functional Reference Model Diagram 21 See, e.g., Verizon Wireless Comments at 6, Verizon Wireless Reply Comments at 2-3, Rural Cellular Association (RCA) Comments at 2-4, Alltel Comments at 2. 22 See WARN Act, § 602(a). 23 Had Congress, as some commenters suggest, intended to require that the Commission adopt the CMSAAC’s recommendations “as is,” Congress would have simply said so. Moreover, the commenters’ reading of the statute appears inconsistent with Congress’ direction that both the CMSAAC and the Commission, separately, consult NIST. Cf, WARN Act § 602(a) and § 603(g). There would have been no need for the Commission to consult NIST again if, as the commenters suggest, Congress intended the Commission to simply adopt the CMSAAC’s recommendations “as is.” 24 Ericsson Comments at 5. 25 See CMSAAC recommendations, § 2.1, figure2-1 (CMAS Functional Reference Model). State EOC Federal Agencies Local Emergency Operations Center (EOC) Alert Aggregator Alert Gatewa y CMS Provider Gateway CMS Provider Infrastructure Mobile Device Proposed Government AdministeredA C B D E Federal Communications Commission FCC 08-99 7 Under this proposed reference model, a Federal government entity, the “Alert Aggregator,” operating under a “Trust Model,”26 would receive, aggregate, and authenticate alerts originated by authorized alert initiators (i.e., Federal, state, tribal and local government agencies) using the Common Alerting Protocol (CAP).27 The Federal government entity would also act as an “Alert Gateway”28 that would formulate a 90 character alert based on key fields in the CAP alert sent by the alert initiator.29 Based on CMS provider profiles maintained in the Alert Gateway, the Alert Gateway would then deliver the alert over a secure interface operated by the CMS provider30 to another gateway maintained by the appropriate CMS provider (CMS Provider Gateway).31 Each individual CMS Provider Gateway would be responsible for the management of the particular CMS provider elections to deliver alerts. The CMS Provider Gateway would also be responsible for formulating the alert in a manner consistent with the individual CMS provider’s available delivery technologies, mapping the alert to the associated set of cell sites/paging transceivers, and handling congestion within the CMS provider infrastructure. Ultimately, the alert would be received on a customer’s mobile device. The major functions of the mobile device would be to authenticate interactions with the CMS provider infrastructure, to monitor for CMAS alerts, to maintain customer options (such as the subscriber’s opt-out selections), and to activate the associated visual, audio, and mechanical (e.g., vibration) indicators that the subscriber has indicated as options when an alert is received on the mobile 26 See CMSAAC recommendations, § 8. 27 The Common Alerting Protocol (CAP) refers to Organization for the Advancement of Structured Information Standards (OASIS) Standard CAP-V1.1, October 2005. 28 See CMSAAC recommendations, § 2.2.4 29 Provisions have also been made for authorized alert originators to formulate and distribute alerts via the Alert Gateway in free text. See e.g., CMSAAC recommendations, § 5.3.2,. 30 See CMSAAC recommendations, § 2.3.1. 31 See CMSAAC recommendations, § 2.3.2. Federal Communications Commission FCC 08-99 8 device.32 As part of its recommended model, the CMSAAC also proposed technical standards defining the functions of the Alert Aggregator, Alert Gateway, CMS Provider Gateway, CMS infrastructure, CMS handsets and various interfaces (i.e., A, B, C, D and E interfaces).33 11. In the CMAS NPRM, we sought comment on the CMSAAC’s proposed reference architecture, including its standards for defining the various element functions.34 Although most commenters supported the CMSAAC’s proposal, a few objected to the CMSAAC’s recommendation concerning the government-administered Alert Aggregator and an Alert Gateway. The Association of Public Television Stations (APTS) suggested that the Commission’s role under the WARN Act is limited to adopting protocols to enable mobile services to opt into the Digital Emergency Alert System (DEAS).35 CellCast asserted that a national Aggregator/Gateway is not required for CMAS implementation and that there are multiple models for alert distribution that do not use such an element.36 DataFM and the National Association of Broadcasters (NAB) raised concerns that a national aggregator would create a single point of failure that would reduce CMAS resiliency and/or introduce unacceptable performance degradation.37 12. According to the CMSAAC, a key element to CMS providers’ ability to participate in the CMAS is the assumption of the Alert Aggregator and Alert Gateway functions by a Designated Federal Government Entity.38 Specifically, the CMSAAC recommended that the CMAS channel all Commercial Mobile Alert Messages (CMAMs) submitted by Federal, State, Tribal and local originators through a secure, Federal government administered, CAP- based alerting framework that would aggregate and hand off authenticated CMAMs to CMS Provider Gateways.39 We sought comment on this recommendation in the CMAS NPRM.40 The 32 See CMSAAC recommendations, § 2.3.5. 33 Each interface in the CMSAAC Reference Architecture represents a place where two elements in the Reference Architecture meet or connect. The “A” interface represents that connection between the alert initiator and the Alert Aggregator, the “B” interface represents the connection between the Alert Aggregator and Alert Gateway, the “C” interface represent the connection between the Alert Gateway and the CMS Provider Gateway, the “D” interface represents the connection between the CMS Provider Gateway and the CMS provider infrastructure, and the “E” interface represents the connection between the CMS provider infrastructure and the mobile device. For the purposes of this Order, the most important interfaces are the “C” and “E” interfaces. The “C” interface requires common protocols that will ensure that the alert information that flows from the Federal government administered Alert Gateway and the CMS providers is secure and accurate. Accordingly, both the Alert Gateway and CMS Provider Gateway must operate under a common set of protocols. The “E” interface will determine what information will appear on the mobile device. It is essential that the requirements for this interface allow accurate, timely, and accessible alerts for the mobile device user. 34 See CMAS NPRM, 22 FCC Rcd at 21979-80, ¶¶ 12-13. 35 See APTS Comments at 2-3. The Digital Emergency Alert System (DEAS) is a next generation alert and warning system that leverages the transition of television to DTV format. 36 See CellCast Comments at 24. 37 DataFM Comments at 10, NAB Comments at 2-3. 38 See CMSAAC recommendations, § 2.2. 39 See CMSAAC recommendations, § 2.2.2 40 CMAS NPRM, 22 FCC Rcd at 21979-80, ¶¶ 12-13. Federal Communications Commission FCC 08-99 9 overwhelming majority of commenting parties supported the CMSAAC’s recommendation.41 Most wireless carriers commenting on the issue stressed that this was essential to CMS providers’ participation in the CMAS. ALLTEL, for example, stated that if “a federal government entity does not assume these roles, wireless service providers are less likely to participate” in the CMAS because “in an emergency situation it is imperative that wireless service providers are able to rely on a single source . . . and government officials are more appropriately trained in authenticating and constructing messages.”42 13. We adopt the CMSAAC’s proposed architecture for the CMAS.43 We find that the recommended model will facilitate an effective and efficient means to transmit alerts and find that the public interest will be served as such. Contrary to APTS’s assertions, nothing in section 602(a) of the WARN Act mandates that we only adopt requirements for CMS providers to opt into DEAS.44 While we agree with CellCast that there are other potential models for alert delivery by electing CMS providers, we note that none of those alternative solutions received the support of the CMSAAC. Moreover, we note that the CMSAAC recommendation is the result of consensus among commercial wireless carriers and their vendors, public safety agencies, organizations representing broadcast stations and organizations representing people with disabilities and the elderly, and other emergency alert experts. This consensus was reached after approximately ten months of deliberation. No other party has suggested an alternative that would be superior in meeting the needs of the commercial wireless industry and in ensuring that alerts are received by electing CMS providers and then are transmitted to their subscribers. In fact, both during the CMSAAC deliberations as well as throughout this proceeding, many wireless carriers have indicated that the inclusion of an alert aggregator and alert gateway function is essential to their participation in the voluntary CMAS.45 14. Finally, we disagree with the concerns raised by DataFM and NAB that a national aggregator would necessarily create a single point of failure. While the CMSAAC recommended a single logical aggregator/gateway function, we expect that these functions will be implemented 41 See generally, Alltel Communications LLC (Alltel) Comments at 4, AT&T Inc. (AT&T) Comments at 6, T- Mobile Comments at 7, and the California Public Utilities Commission (CAPUC) Comments at 6,7. But see, e.g., Ken Post Comments at 2 (CMAS should be based on a shred authority system as envisioned by the National Incident Management System), National Association of Broadcasters (NAB) Comments at 2-3 (a government-run aggregator creates a complex single system that has the potential to be a single point of failure), CellCast Comments at 7-9 (aggregator is not required for CMAS implementation, either at the National, State, or local levels). 42 Alltel Comments at 4. 43 See CMSAAC recommendations, §§ 2.3.5 and 7. 44 As noted, infra at ¶¶ 34-41 the CMSAAC recommendations and this First Report and Order consistently conclude that the requirements for the CMAS should be technologically neutral. APTS’s arguments regarding equipment are more appropriately addressed in the order that addresses section 602(c) of the WARN Act. 45 AT&T Comments at 6 (“it is critical to the success… that a single Government Entity serve as the alert aggregator and gateway… whether it assumes this role directly or via a third party contractor “); CTIA Comments at 2 (Commission adoption of the CMSAAC recommendations as submitted will encourage the highest level of participation); T-Mobile Comments at 15, 16 (Centralization is key to the proper functioning of a CMAS, and that it must be managed by the federal government. Without the centralized system, participation at all these levels could result in chaos). Federal Communications Commission FCC 08-99 10 in a reliable and redundant fashion to maximize resiliency.46 Furthermore, given the volume of alerts expected for the CMAS, we believe that technology for processing alerts will not place a constraint on aggregator/gateway performance.47 Accordingly, we adopt the architecture proposed by the CMSAAC. As described below, however, we adopt as rules only those CMAS elements within the control of the CMS providers. 15. Federal Government Role. We agree with the CMSAAC and the majority of commenters that a Federally administered aggregator/gateway is a necessary element of a functioning CMAS. While no Federal agency has yet been identified to assume these two functions,48 we believe that a Federal government aggregator/gateway would offer the CMS providers the best possibility for the secure, accurate and manageable source of CMAS alerts that the WARN Act contemplates. 16. We believe that FEMA, some other entity within DHS, or NOAA may be in the best position to perform these functions.49 DHS, and more specifically FEMA, traditionally has been responsible for origination of Presidential alerts and administration of the EAS.50 Moreover, Executive Order 13407 gives DHS primary responsibility for implementing the United States’ policy “to have an effective, reliable, integrated, flexible and comprehensive system to alert and warn the American people in situations of war, terrorist attack, natural disaster or other hazards to public safety and well-being.”51 By the same token, the Department of Commerce, and more specifically NOAA Weather Radio, as the "All Hazards" radio network, acts as the source for weather and emergency information, including natural (such as earthquakes 46 See CMSAAC recommendations at 71. The CMSAAC recommended that CMAS system reliability meet “telecom standards for highly reliable systems,” which generally implies the use of redundant elements where single points of failure would otherwise exist. 47 Based on the CMAS alert volumes anticipated by the CMSAAC in section 11 of the CMSAAC recommendations, we agree with the CMSAAC’s view that developing the technology for processing alerts according to the CMSAAC proposed timeline will not overburden the aggregator/gateway performance. 48 See FEMA Comments at 2 (stating that although it supports the CMSAAC’s recommendations, it “[do[es] not have the authority during non-emergency periods to develop, implement, operate or maintain elements of the CMAS that regard alerts, warnings or notifications originated by state and local authorities such as the Aggregator and Gateway functions of the Trust Model of the CMAS, under [its] current statutory authority.”) 49 FEMA administers the Emergency Alert System (EAS) while NOAA operates the NOAA Weather Radio (NWR). See http://www.weather.gov/nwr/ (last viewed on April 7, 2008). The respective roles of the Commission, FEMA, and NOAA are based on a 1981 Memorandum of Understanding, see State and Local Emergency Broadcasting System (EBS) Memorandum of Understanding Among the Federal Emergency Management Agency (FEMA), Federal Communications Commission (Commission), and the National Oceanic and Atmospheric Administration (NOAA) (Approved by National Industry Advisory Committee (NIAC) on April 21, 1982), a 1984 Executive Order, Assignment of National Security and Emergency Preparedness Telecommunications Functions, Exec. Order No. 12,472, 49 Fed. Reg. 13,471 (1984), and a 1995 Presidential Statement of Requirements, see Presidential Communications with the General Public During Periods of National Emergency, The White House (September 15, 1995). 50 While the FCC could perform this role, additional funding to support such an undertaking would likely be necessary. We note that unlike the FCC, DHS and the Department of Commerce have authority under the WARN Act to borrow up to $106 million against Digital Television (DTV) transition revenues in order to fulfill their obligations under the statute. See WARN Act, § 606(c). It is also our understanding that FEMA has funding for its Integrated Public Alert and Warning System. 51 Executive Order 13407, § 1. Federal Communications Commission FCC 08-99 11 or avalanches), environmental (such as chemical releases or oil spills), and public safety (such as AMBER alerts or 911) warning information.52 17. FEMA also played an integral role in the development of the CMSAAC’s recommendations. FEMA chaired the Alert Interface Group (AIG), which was responsible for addressing issues at the front-end of the CMAS architecture (e.g., receipt and aggregation of alerts, development of trust model to authenticate alerts from various sources). It also represented the AIG before the CMSAAC Project Management Group (PMG), which coordinated the work of all the other CMSAAC working groups and assembled the CMSAAC recommendations document. In addition, FEMA voted to adopt the CMSAAC recommendations in October 2007, which included CMAS reliance on a single Federal authority to fulfill the gateway/aggregator role. 18. We recognize that FEMA asserted in its February 2008 comments that limits on its statutory authority preclude the agency from fulfilling the Federal aggregator/gateway functions.53 Nevertheless, timely identification of a federal agency capable of fulfilling the aggregator/gateway functions recommended by the CMSAAC is essential to bringing the concrete public safety benefits of a CMAS system to the American people.54 We are hopeful that any bars that prevent FEMA or some other entity within DHS from fulfilling these roles will be lifted expeditiously. We will work with our Federal partners and Congress, if necessary, to identify an appropriate government entity to fulfill these roles, whether that is FEMA, another DHS entity, NOAA or the FCC. 19. Scope of Order. Accordingly for purposes of this Order, we proceed on the assumption that a Federal agency will assume these roles at a future date. Today’s Order is limited to adopting rules governing those sections of the CMAS architecture that are within the control of electing CMS providers.55 These include rules regarding the CMS Provider Gateway, CMS provider infrastructure, and CMS provider handsets. Specifically, we adopt rules, based on the CMSAAC’s recommendations, that require each individual CMS Provider Gateway to be able to receive alerts from the Federal government alert gateway over a secure interface (i.e., “C Interface”).56 The CMS Provider Gateway will be required to, among other things: (1) manage 52 FEMA administers the Emergency Alert System (EAS) while NOAA operates the NOAA Weather Radio (NWR). See http://www.weather.gov/nwr/ (last viewed on April 7, 2008). The respective roles of the Commission, FEMA, and NOAA are based on a 1981 Memorandum of Understanding, see State and Local Emergency Broadcasting System (EBS) Memorandum of Understanding Among the Federal Emergency Management Agency (FEMA), Federal Communications Commission (Commission), and the National Oceanic and Atmospheric Administration (NOAA) (Approved by National Industry Advisory Committee (NIAC) on April 21, 1982), a 1984 Executive Order, Assignment of National Security and Emergency Preparedness Telecommunications Functions, Exec. Order No. 12,472, 49 Fed. Reg. 13,471 (1984), and a 1995 Presidential Statement of Requirements, see Presidential Communications with the General Public During Periods of National Emergency, The White House (September 15, 1995). 53 See FEMA Comments at 2. 54 Accordingly, the compliance date for the rules we adopt today is tied to the announcement of an entity to fulfill these functions. The absence of an aggregator/gateway, however, will have no impact on a CMS provider’s obligation under the WARN Act to elect whether or not it intends to transmit emergency alerts within 30 days of the Commission’s issuance of rules required under section 602(b). See WARN Act, § 602(b). 55 A complete list of the required CMS infrastructure functions is set forth in the rules in Appendix C. 56 The C interface is a secure interface over which alerts can be passed from the Aggregator/Gateway to the CMS Provider Gateway. Under our rules, the CMS provider must: (1) provide information for the authentication and (continued....) Federal Communications Commission FCC 08-99 12 the CMS provider’s election to provide alerts; (2) format alerts received in a manner consistent with the CMS provider’s available delivery technology; (3) map alerts to the associated set of cell sites/paging transceivers; and (4) manage congestion within the CMS provider’s infrastructure.57 In addition, we adopt rules, based on the CMSAAC’s recommendations, requiring the CMS infrastructure to, among other things: (1) authenticate interactions with the mobile device; (2) distribute received CMAS alert messages to the appropriate set of cell sites/paging transceivers for transmission to the mobile device; and (3) transmit the CMAS alert message for each specified cell site/pager transceiver.58 20. We adopt the CMSAAC’s recommendations regarding capabilities of the mobile device including that it: (1) authenticate interactions with the CMS provider infrastructure; (2) maintain configuration of CMAS alert options; and (3) present received CMAS alert content to the subscriber.59 In addition, as explained below, we adopt requirements for the mobile device to ensure that people with disabilities are able to receive CMAS alerts.60 We also adopt the CMSAAC’s recommendation that CMAS alerts not preempt ongoing voice or data sessions.61 21. In keeping with our policy to promote technological neutrality, we decline to adopt rules governing the communications protocols that the CMS providers must employ for communications across the D or E interfaces as identified in the architecture.62 We agree with the CMSAAC that no specific protocols should be required for the D and E interface, but rather that CMS providers should be allowed to retain the discretion to define these protocols in conjunction with their overall network design and with the mobile device vendors.63 Both of these interfaces lie entirely within the control of the CMS providers and any implementation decisions there will have no impact on CMAS ability to satisfy the system requirements we set forth elsewhere in this Order.64 For example, while we do include requirements on the type of (...continued from previous page) validation of actions across the interface; (2) be able to receive new, updated or cancelled wireless alert messages from the Alert Gateway in a format that is suitable for the mobile devices and the wireless alert deliver technology or technologies implemented by the CMS provider; and (3) acknowledge the receipt of new, updated or cancelled wireless alert messages. 57 A complete list of the CMS Provider Gateway’s required functions is set forth in the rules in Appendix C. 58 Interstate Wireless supports the CMSAAC recommended reference architecture, but notes that the cost of building and maintaining a CMS Provider Gateway would be more than it and other similarly situated Small Business CMS providers could afford and still be able to provide the alert service to the public without cost. Accordingly, Interstate Wireless requests that the Federal Government either provide the proper software and reception equipment for the CMS Provider Gateways, or provide grants to the Small Business CMS providers to purchase, install, and maintain the equipment themselves. Interstate Wireless Comments at 6. We acknowledge the concern of Interstate Wireless, but note that questions of funding are not addressed by section 602(a) of the WARN Act, and thus are outside of the scope of this order. 59 CMSAAC recommendations, § 1.1.1. 60 See infra ¶¶ 57-67. 61 CMSAAC recommendations, § 7.3. 62 See Functional Reference Model Diagram, supra ¶ 10. 63 No commenter objected to this recommendation. 64 For this reason, we conclude that our decision is consistent with section 602(a) of the WARN Act which requires that we adopt technical requirements “necessary” for CMS alerting capability. WARN Act, § 602(a). Federal Communications Commission FCC 08-99 13 alert information that must cross the D and E interfaces to enable CMAS alerts on mobile devices, we choose to remain silent as to the precise communications protocol that a CMS provider uses to convey this information to the mobile device.65 This approach gives the CMS providers maximum flexibility to leverage technological innovation and implement the CMAS in a cost effective manner. 22. We also adopt rules requiring, per the CMSAAC’s recommendation, that electing CMS providers assemble individual profile information to provide to the Authorized Federal Government Entity, once that entity is identified.66 We believe that electing CMS providers expect to assemble this information, and by adopting this requirement now, we are providing direction to potential Alert Gateway providers.67 23. The CMSAAC recommended detailed technical protocols and specifications for the Alert Aggregator/Gateway entity and the CMS providers to employ for the delivery of alerts over the various interfaces (i.e., A, B and C interfaces) in the Reference Model. Specifically, section 10 of the CMSAAC recommendations proposed requirements that Alert Initiators must meet to deliver CMAS alerts to the Alert Aggregator, and that the Alert Gateway must meet to deliver CMAS alerts to the CMS Provider Gateway.68 The CMSAAC also recommended CAP- based mapping parameters. 24. We support the technical protocols and specifications for the delivery of alerts recommended by the CMSAAC in this section. Electing CMS providers could use these technical protocols and specifications to design their internal systems that would enable compliance with the rules we adopt in this docket. We decline, however, to codify these protocols and specifications in this Order. We believe that these protocols offer a significant guidance to CMAS participants as they further develop the final protocols and interface for the CMAS, but until an Alert Aggregator/Gateway entity is determined, additional refinements and revisions of these protocols and specifications are inevitable. Accordingly, we conclude that final determination of these interface protocols is better left to industry standards organizations.69 We will revisit this matter in the future if Commission action in this area is indicated. C. General CMAS Requirements 25. In this section, we establish the basic regulatory framework of the new CMAS. Specifically, we adopt technologically neutral rules that address, among other things, the scope of CMAS alerts, geo-targeting and alert accessibility for people with disabilities and the elderly. 1. Scope and Definition of CMAS Alerts 26. The WARN Act requires the Commission to enable commercial mobile alerting capabilities for “emergency” alerts,70 but does not define what may comprise an emergency. 65 See infra, ¶¶ 26-30 (discussion of CMAS Alert Categories). 66 See CMSAAC recommendations, § 2.2.4.2. 67 See CMSAAC recommendations, § 2.2.4.2 and Table 2.1. 68 See CMSAAC recommendations, § 10. 69 We note that the Alliance for Telecommunications Industry Solutions (ATIS) and Telecommunications Industry Association (TIA) are beginning to engage in standards setting related to the CMAS. See ATIS Comments at 4-5. 70 WARN Act, § 602(b)(2)(e). Federal Communications Commission FCC 08-99 14 Accordingly, in the CMAS NPRM, we sought comment on the appropriate scope of emergency alerts, including whether and to what extent alerts should be classified.71 We specifically asked parties to address whether we should implement the CMSAAC’s recommendation to specify three alert classes: (1) Presidential Alert; (2) Imminent Threat Alert; and (3) Child Abduction Emergency or AMBER Alert.72 For the reasons stated below, we find that the public interest will be best served by our adopting these three alert classes, and we define them below. 27. We agree with the majority of commenters that the three classes of alert recommended by the CMSAAC achieves the best balance between warning of imminent threat to life and property with the current technical limits that CMS provider systems face in delivering timely, accurate alerts.73 Alert Systems however argues that we should include additional classes of alerts, such as traffic advisories.74 We find that inclusion of such alerts would be inconsistent with the intent of Congress, expressed throughout the WARN Act, that the Commission enable an “emergency” alerting system. We believe that if the public were to receive commercial mobile alerts that do not relate to bona fide emergencies, there would be a serious risk that the public would disregard mobile alerts or possibly opt not to receive anything but Presidential alerts.75 We also note that, given the current technical capabilities of CMS providers to deliver emergency alerts, it is possible that if too many alerts are injected into a CMS provider’s system in a very brief period, vital messages could be delayed. Accordingly, we reject arguments to broadly define eligible alert classes beyond those specified here. a. Presidential Alerts 28. Section 602(b)(2)(E) of the WARN Act authorizes participating CMS providers to allow device users to prevent the receipt of alerts or classes of alerts “other than an alert issued by the President.”76 Congress thus intended to afford Presidential Alerts the highest priority. Affording Presidential Alerts the highest priority also will enable the Secretary of Homeland Security to meet his/her obligation, under Executive Order 13407, to “ensure that under all conditions the President of the United States can alert and warn the American people.”77 Accordingly, electing CMS providers must transmit such alerts and assign the highest priority to any alert issued by the President or the President’s authorized designee.78 Further, Presidential Alerts must be transmitted upon receipt by a CMS provider, without any delay, and therefore will preempt any other pending alert. We note that due to the initial 90-character text message 71 CMAS NPRM, 22 FCC Rcd at 21981, ¶16. 72 Id. 73 CMSAAC recommendations at § 5.1. See also CAPUC Comments at 10-11. 74 Alert Systems Comments at 16 (urging more than three classification levels, claiming disaster managers need the ability to dispatch road closure and other community relevant information). 75 See MetroPCS Comments at 3 (noting that if too many alert messages are transmitted, users may ignore them); T- Mobile Comments at 10 (“[s]ubscribers will be more likely to opt out of CMAS altogether if their devices are inundated with minor alerts”). 76 WARN Act, § 602(b)(2)(e). 77 Executive Order 13407, § 2(a)(x). 78 See CMSAAC recommendations, § 2.3.2 (CMS providers will prioritize Presidential alerts). Federal Communications Commission FCC 08-99 15 protocol that we are adopting below for the first generation CMAS,79 it is possible that a Presidential Alert may direct recipients to other sources, possibly taking the form recommended by the CMSAAC: “The President has issued an Emergency Alert. Check local media for more details.”80 b. Imminent Threat Alerts 29. We note that virtually all commenting parties support adoption of the CMSAAC’s recommendation to define an Imminent Threat Alert class.81 This alert class is narrowly tailored to those emergencies where life or property is at risk, the event is likely to occur, and some responsive action should be taken. Specifically, an Imminent Threat Alert must meet separate thresholds regarding urgency, severity, and certainty. Each threshold has two permissible CAP values. · Urgency. The CAP “urgency” element must be either Immediate (i.e., responsive action should be taken immediately) or Expected (i.e., responsive action should be taken soon, within the next hour).82 · Severity. The CAP “severity” element must be either Extreme (i.e., an extraordinary threat to life or property) or Severe (i.e., a significant threat to life or property).83 · Certainty. The CAP “certainty” element must be either Observed (i.e., determined to have occurred or to be ongoing) or Likely (i.e., has a probability of greater than fifty percent).84 That is, the event must have occurred, or be occurring (Observed), or be more likely to occur than not (Likely). 30. We find that the transmission of these imminent threat alerts is essential to a useful CMAS. The CMSAAC recommended such action and the commenting parties overwhelmingly support this conclusion.85 As T-Mobile correctly states, CMAS alerts are not appropriate for warning the public about minor events.86 Subscribers are more likely to opt out if they are bombarded by minor notices, and may fail to notice a truly serious alert. Also, inclusion of minor events would be an unnecessary burden on the CMS provider infrastructure. Accordingly, we find it appropriate to require participating CMS providers to transmit Imminent Threat Alerts. 79 See infra ¶¶ 82-83. 80 CMSAAC recommendations, § 5.3.3. 81 But cf. CellCast Comments at 29 (opposing adoption of alert classes). 82 See CAP-V1.1 at 16. 83 See CAP-V1.1 at 17. 84 Id. 85 See supra, n.20. 86 T-Mobile Comments at 9-10. Federal Communications Commission FCC 08-99 16 c. Child Abduction Emergency/AMBER Alerts 31. There is broad support in the record for adoption of the CMSAAC’s recommendation to specify a third alert class, Child Abduction Emergency or AMBER Alert.87 There are four types of AMBER Alerts: (1) Family Abduction,88 (2) Nonfamily Abduction,89 (3) Lost, Injured, or Otherwise Missing,90 and Endangered Runaway.91 AMBER plans are voluntary partnerships between law enforcement agencies, broadcasters and CMS providers to activate an urgent bulletin in the most serious child abduction cases, and AMBER alerts are issued only where an AMBER plan has been duly established.92 We also note that a number of CMS providers currently transmit AMBER Alerts using Short Message Service (SMS) technology,93 and we applaud their potentially life-saving efforts in this regard. 32. In 2006, 261 AMBER Alerts were issued in the United States involving 316 children.94 Most of these alerts were issued on an intrastate basis.95 Of the 261 AMBER Alerts issued in 2006, 214 cases resulted in a recovery, 53 of which were resolved as a direct result of an AMBER Alert being issued.96 Based on the limited number of AMBER alerts and their confined geographic scope, we do not expect such alerts to be overly burdensome to CMS providers that participate in the CMAS. Moreover, because of the efficacy of AMBER Alerts, we find that the public interest in the safety of America’s children will be well served by the 87 See, e.g., Acision Comments at 6-7 (supporting the inclusion of AMBER alerts to, among other things, maintain public awareness of the CMAS). We note that on April 30, 2003, President George W. Bush signed the Prosecutorial Remedies and Other Tools to end the Exploitation of Children Today (PROTECT) Act of 2003 (Pub. L. No. 108-21,117 Stat 650 (Apr. 20, 2003)) into law. Building on the steps already taken by the Federal Government to support AMBER Alerts, this Act codified the national coordination of state and local programs, including the development of guidance for issuance and dissemination of AMBER Alerts and the appointment of a national AMBER Alert Coordinator. 88 A Family Abduction (FA) involves an abductor who is a family member of the abducted child such as a parent, aunt, grandfather, or stepfather. See http://www.amberalert.gov/statistics.htm. 89 A Nonfamily Abduction (NFA) involves an abductor unrelated to the abducted child, either someone unknown to the child and/or the child’s family or an acquaintance/friend of the child and/or the child’s family. Id. 90 A Lost, Injured, or Otherwise Missing (LIM) involves a case where the circumstances of the child’s disappearance are unknown. Id. 91 An Endangered Runaway (ERU) involves a missing child who is believed to have run away and in imminent danger. Id. 92 Localities generally establish AMBER plans based on the U.S. Department of Justice’s five criteria that should be met before an alert is activated: (1) law enforcement confirms a child has been abducted; (2) the child is 17 years or younger; (3) law enforcement believes the child is in imminent danger of serious bodily harm or death; (4) there is enough descriptive information about the victim and the abduction to believe an immediate broadcast alert will help; and (5) the child’s name and other data have been entered into the National Crime Information Center. See http://www.amberalert.gov/. 93 See How Wireless AMBER Alerts™ Are Sent, available at http://wirelessamberalerts.adcouncil.org/howwirelessamberalertswork.htm. 94 See National Center for Missing & Exploited Children, 2006 AMBER-Alert Report at 7. 95 In 2006, 11 AMBER Alerts were extended beyond the limits of the state where the alert first originated. Id. at 8. Eight alerts were extended to one additional state, and three alerts were extended to two states each. Id. 96 Nine (9) children were recovered deceased, and, as of April 21, 2007, 10 cases remained active with 11 children still missing. Id. Federal Communications Commission FCC 08-99 17 provision of AMBER Alerts by the wireless industry. Accordingly, we require participating CMS providers to transmit AMBER alerts. 2. Technologically Neutral Alert System 33. The CMSAAC recommended that CMS providers that elect to participate in the CMAS should “not be bound to use any specific vendor, technology, software, implementation, client, device, or third party agent, in order to meet [their] obligations under the WARN Act.”97 We agree. As SouthernLINC notes, participating CMS providers should be able to choose the technology that will allow them to best meet the emergency alerting needs of the American public.98 Consistent with the Commission’s well-established policy of technologically-neutral regulation of the wireless telecommunications industry,99 we believe that CMS providers and equipment manufacturers are in the best position to select and incorporate the technologies that will enable them to most effectively and efficiently deliver mobile alerts. Accordingly, we will not limit the range of technologies that electing CMS providers may deploy to participate in the CMAS. In reaching this conclusion, we have balanced the alerting needs of the public and the capabilities of electing CMS providers and our mandate under section 602(a) of the WARN Act to enable the provision of emergency alerts.100 We emphasize that the WARN Act does not require the establishment of any specific technology to be used for the CMAS. 34. CMS providers are in various stages of readiness to participate in the CMAS. Paging carriers already provide point to multipoint services, using technologies such as ReFLEX and POCSAG (Post Office Code Standardization Advisory Group), to reach many subscribers at the same time and therefore appear well-positioned to participate in CMAS.101 However, as the American Association of Paging Carriers notes, it may not be feasible for paging carriers to confine their alerts to either county-wide or sub-county distribution.102 Further, cellular, PCS, and SMR service providers, report that they have not deployed an emergency alerting capability that satisfies all requirements in the CMSAAC recommendations and that is currently available for the mass transmission of alerts.103 We note that many of the requirements that we adopt today are intended to apply to a first generation text-based alerting service. Other service profiles, such as streaming audio and video, are in their early developmental stages and thus not ripe for implementation by the Commission. We foresee that as CMS providers gain experience 97 CMSSAC recommendations, §5.1. 98 SouthernLINC Comments at 4-6. 99 See Amendment of the Commission's Rules to Permit Flexible Service Offerings in the Commercial Mobile Radio Services, WT Docket No. 96-6, Second Report and Order and Order on Reconsideration, 15 FCC Rcd 14680 (2000). 100 WARN Act, § 602(a). 101 ReFLEX is a wireless network protocol developed by Motorola which is used for two-way paging. Narrowband PCS carriers use the ReFLEX technology protocol, which can transmit data at speeds ranging from 3.2 to 25 kbps. See Tenth CMRS Competition Report, 20 FCC Rcd at 15955, ¶ 124. For more information regarding ReFLEX, see http://usamobility.com/pdf/ReFLEX2.pdf. For more information regarding POCSAG, see http://www.wireless.per.nl/reference/chaptr01/dtmmsyst/paging.htm. 102 See AAPC Comments at 7. 103 See, e.g., Sprint Nextel Comments at 8-9 (noting that certain industry standardization processes must be completed before CMAS deployment). Federal Communications Commission FCC 08-99 18 with these and other alerting technologies, they may well be incorporated into future alerting system deployments. 35. Although the CMSAAC found that point-to-point technologies may not be well suited for mass alerting,104 we will not prohibit their use if a CMS provider can otherwise meet the requirements that we establish today. Short Message Service (SMS)105 text messaging is available to most cellular, PCS, and SMR subscribers and is currently used by some municipalities and other local jurisdictions to provide emergency alerts on an opt-in basis.106 We recognize, however, that SMS may not be a desirable solution for the widespread dissemination of alerts to the public because the mass delivery of SMS-formatted alerts could degrade network performance and delay alert delivery. Despite these potential drawbacks, SMS text messaging may offer a viable, short-term delivery method for electing CMS providers that do not yet have a point-to-multipoint text messaging capability.107 36. The CMSAAC noted that technologies such as MediaFLO and DVB-H “may provide supplemental alert information,”108 but recommended that they should not be considered as part of the CMAS.109 Our goal in this proceeding is to enable the broadest possible voluntary participation in the CMAS, and we will not foreclose the possible deployment of these or other innovative technologies as a means of participating in the nascent CMAS. The public interest is best served by not circumscribing the range of technologies that CMS providers may elect to deploy to meet the alerting needs of the American public. 37. Several parties express support for an FM-based CMAS solution such as that provided by ALERT-FM and Global Security Systems.110 The CMSAAC however considered the costs and benefits of Radio Broadcast Data System (RBDS) and other FM-based alert and warning solutions, and found them to be infeasible for the CMAS. 111 Moreover, a number of 104 According to the CMSAAC, point-to-point technologies may experience delivery delays, network congestion, and lack geo-targeting capabilities because alerts are targeted to phone numbers instead of a specific alert area. See CMSAAC recommendations at § 5.2. 105 SMS enables the transmission of alphanumeric messages between mobile subscribers and external systems such as electronic mail, paging, and voice mail systems. For a more complete description, see http://electronics.howstuffworks.com/sms1.htm and http://www.mobilein.com/SMS_tutorial.pdf. 106 The District of Columbia and many of its neighboring jurisdictions, for example, have such emergency alert systems. See http://textalert.ema.dc.gov (Alert DC); http://www.fairfaxcounty.gov/cean (Fairfax County, VA); http://alert.montgomerycountymd.gov (Montgomery County, MD). 107 Many CMS providers are successfully using SMS today to transmit geographically specific AMBER Alerts to interested subscribers. The wireless AMBER alert system notifies wireless customers who have elected to receive the service of missing children alerts. Information regarding the system is available at http://www.wirelessfoundation.org/amber. Thirty-two wireless carriers currently participate in the system. See http://wirelessamberalerts.adcouncil.org/partners.htm. 108 CMSAAC recommendations, § 5.2. Information regarding MediaFLO technology is available at http://www.qualcomm.com/mediaflo/about_us/index.shtml. Information regarding DVB-H technology is available at http:// www.dvb-h.org/technology.htm. 109 CMSAAC recommendations, § 5.2. 110 See, e.g., Comments of Data-FM at 7-8, Sheriff of Jefferson County, Louisiana; Florida Association of Broadcasters, Mississippi Office of Homeland Security, Mississippi Office of Emergency Management. 111 See CMSAAC recommendations at 47-48. Federal Communications Commission FCC 08-99 19 parties have expressed reservations about these technologies.112 Nonetheless, in keeping with our overall policy to maintain technological neutrality, we do not require or prohibit the use of ALERT-FM, RBDS or similar systems as the basis of the CMAS.113 38. We also strongly encourage fair, reasonable, and nondiscriminatory Intellectual Property Rights (IPR) licensing in the context of the CMAS. We agree with the CMSAAC that the technical standards, protocols, procedures, and related requirements that we adopt pursuant to section 602(a) of the WARN Act today should be standardized in industry bodies that have well defined IPR policies.114 We decline, however, to compel all CMSAAC participants “to provide written assurance to the Commission that, if and insofar as one or more licenses may be required under any of their respective IPRs that are technically essential for purposes of implementing or deploying CMAS, the rights holders shall license such IPR on a fair, reasonable and nondiscriminatory basis for those limited purposes only.”115 We also decline to require “all participants in the public comment process on th[e] CMAS Architecture and Requirements document” to make such a written assurance.116 These requests are outside the scope of section 602(a) of the WARN Act. 39. The CMSAAC made a number of additional recommendations that we conclude are outside the scope of our mandate under section 602(a) of the WARN Act to adopt “technical standards, protocols, procedures, and other technical requirements,” to enable voluntary commercial mobile alerting.117 Specifically, the CMSAAC submitted recommendations regarding the applicability of requirements for location, number portability and the Communications Assistance for Law Enforcement Act (CALEA).118 The CMSAAC also submitted recommendations on whether CMS providers may utilize the technical requirements adopted herein for other services and purposes and whether CMS providers may recover certain costs related to the development of the CMAS.119 We find that these issues are outside the scope of section 602(a) of the WARN Act and, therefore, do not address these issues herein. 40. The CMSAAC recommended that, to the extent practicable, “Federal, state, tribal, and local level CMAS alert messages [should] be supported using the same CMAS solution.”120 We agree. We believe that a uniform approach to implementation of the CMAS will be inherently more cost effective, more technologically consistent and thus more likely to facilitate participation by small and rural CMS providers. Further, we agree that electing CMS providers should not be required to support alerting on mobile handsets manufactured for sale to the public prior to a CMS provider’s initiation of the CMAS alerting service. In a subsequent order, we 112 See e.g., AT&T Reply Comments at 11-12. 113 CMS providers have discretion to use these technologies so long as they are able to transmit emergency alerts in a manner consistent with the rules we adopt today. 114 CMSAAC recommendations, § 5.1. 115 Id. 116 Id. 117 WARN Act, § 602(a). 118 CMSAAC recommendations, § 5.2.4. 119 CMSAAC recommendations, § 5.1 120 Id. Federal Communications Commission FCC 08-99 20 will address how participating CMS providers may sell such non-compliant handsets consistent with the requirement under section 602(b) of the WARN Act that they disclose “at the point of sale of any devices with which its commercial mobile service is included, that it will not transmit such alerts via the service it provides for the device.”121 Finally, we agree that electing CMS providers should have discretion regarding whether certain devices, such as laptop wireless data cards, will support alerting capabilities. 3. CMAS Message Elements and Capabilities a. Required Alert Message Elements 41. The CMSAAC recommended that emergency alert messages follow the same general format of National Weather Service alert messages, subject to a 90-character text limitation.122 Specifically, the CMSAAC recommended that for initial CMAS deployments, messages should include five elements in the following order: · Event Type or Category · Area Affected · Recommended Action · Expiration Time (with time zone) · Sending Agency The CMSAAC proposed this format to facilitate CAP value field mapping to text.123 It also noted that the format would likely evolve as experience is gained by alert initiators and by electing CMS providers.124 In the CMAS NPRM, we sought comment on the five elements and asked parties to address whether the elements are consistent with accepted industry practices for emergency alerts.125 42. There is broad support in the record for standardization of alert messages and adoption of the five recommended message elements. T-Mobile explains that the format “is designed to ensure that the most critical information is succinctly and clearly communicated in a manner most compatible with the technical attributes of wireless networks.”126 Purple Tree Technologies also supports the five message elements, but urges that event type and area affected be the only required elements, with others optional if space permits.127 Based on our review of the record, we find that on balance the five message elements identified above will enable standardization of alerting messages and we hereby adopt them. We reject Alert Systems’ claim that the element for “area affected” should be reconsidered, based on its hypothesis that “visitors and newcomers to areas often do not recognize geographic landmarks in warning 121 WARN Act, § 602(b). 122 CMSAAC recommendations, § 5.3.1. 123 Id. 124 Id. 125 CMAS NPRM, 22 FCC Rcd at 21981, ¶18. 126 T-Mobile Comments at 18. 127 Purple Tree Technologies Comments at 10. Federal Communications Commission FCC 08-99 21 messages.”128 A biohazard or flash flood warning, for example, would not enable the public to avoid a lethal hazard without appropriate area affected information. We also expect that as CMAS providers eventually deploy technologies capable of messages of more than 90 characters, additional alert message elements will be implemented. 43. In the CMAS NPRM, we also sought comment on whether alert messages should include telephone numbers, URLs129 or other response and contact information, including any related network impacts.130 The CMSAAC advised against inclusion of URLs or telephone numbers because such information would encourage mass access of wireless networks.131 The California Public Utility Commission (CAPUC) supports inclusion of a sixth message element for URLs, if feasible.132 AT&T (and many commenting parties) note that inclusion of a URL or telephone number in an emergency message, some of which might be delivered to tens of thousands of users in a matter of seconds, could lead to unacceptable network congestion and, in extreme cases, network failure.133 We find that mandating URLs or telephone numbers in an emergency alert could exacerbate wireless network congestion at a time when network traffic is already dramatically increasing as individuals contact police, fire, and rescue personnel, as well as their loved ones.134 We therefore will not require participating CMS providers to accept or transmit any alert message that contains an embedded URL or telephone number. b. CMAS Generation of Free Text Alert Messages 44. In the CMAS NPRM, we sought comment on the CMSAAC’s recommendation that the Alert Gateway automatically generate messages by extracting information from specified fields of a CAP-formatted message, SAME codes, or free-form text, which would then be transmitted across Reference Point C to electing CMS providers.135 The CMSAAC recommended this approach for initial system deployments.136 We also sought comment on the CMSAAC’s recommendation to allow the generation of free text for Presidential and AMBER 128 Alert Systems Comments at 16-17. 129 URL is an acronym for Uniform Resource Locator and is a reference (an address) to a resource on the Internet. A URL has two main components: a protocol identifier and a resource name, which are separated by a colon and two forward slashes. The protocol identifier indicates the name of the protocol to be used to obtain the resource, such as HTTP (Hypertext Transfer Protocol). HTTP is just one of many protocols used to access different types of resources on the Internet. Other protocols include File Transfer Protocol (FTP), Gopher, File, and News. Additional information regarding URLs is available at http://java.sun.com/docs/books/tutorial/networking/urls/index.html. 130 CMAS NPRM, 22 FCC Rcd at 21981-82, ¶20. 131 See CMSAAC recommendations, § 5.3.2.1. 132 See, e.g., CAPUC Comments at 12. 133 AT&T Comments at 8; T-Mobile Comments at 19-20 (opposing inclusion of URLs, telephone numbers because “such information could cause customers to flood the wireless network resulting in crippling network congestion)” 134 See Alltel Reply Comments at 3 (“network congestion exists during emergencies today and would be made worse by inserting a phone number or URL to encourage people to initiate more calls’); RCA Reply Comments at 7 (inclusion of URLs or telephone numbers could make “it difficult or impossible for anyone to complete a critical telephone call” and possibly “tak[e] the entire wireless network down”). 135 CMAS NPRM, 22 FCC Rcd at 21981, ¶19; CMSAAC recommendations, § 5.3.2. 136 See CMSAAC recommendations, § 5.3.2. Federal Communications Commission FCC 08-99 22 alert messages.137 While numerous parties in this proceeding support adoption of the CMSAAC recommendations in full, few address the specific mechanics of generating alert messages via the Alert Gateway.138 AT&T states that proposals for automatic generation of alert text “merit further investigation, but responsibility for the content of alerts should remain with initiators and the federal government—not wireless carriers.”139 We agree with AT&T and other parties that electing CMS providers should act as a conduit for messages, the content of which is fixed before transmission to a CMS provider. 45. CellCast argues that we should “ignore” the CMSAAC recommendations regarding alert generation, asserting that message generation is beyond our mandate under the WARN Act.140 The mechanisms for generating messages at the Alert Gateway are undefined currently and may be subject to implementation by the federal entity selected to administer the Alert Gateway. Nonetheless, we support the CMSAAC’s recommended approach of allowing the Alert Gateway to create messages using CAP fields and SAME codes.141 Specifically, we believe that this approach would enable the provision of consistent and accurate messages to the public, while facilitating future enhancements to the Alert Gateway. 46. We also agree with the CMSAAC that automatic generation of messages via CAP fields and SAME codes may not always provide sufficient flexibility to alert initiators to tailor messages for emergencies that may fall with the Imminent Threat Alert category.142 A message with a translated event code of “security warning,” for example, may not provide adequate information about a shooting incident on a college campus. A more apt warning might be “a shooting has occurred on the north campus,” with directions to “stay indoors.” We thus believe that the public interest would be served if the CMAS architecture accommodates free-form text messaging, subject to the 90-character text limit that we adopt today and our determination that electing CMS providers will generally not be obligated to accept or transmit any alert message that includes an embedded URL or phone number.143 We also agree with the CMSAAC that free-form text should be included as a CAP message parameter.144 47. Finally, we concur with the CMSAAC that automatic text generation at the Alert Gateway would be impractical for Presidential or AMBER Alerts,145 both of which are likely to be highly fact specific. As the CMSAAC noted, the efficacy of a particular AMBER Alert hinges on specific information such as a description of a vehicle, abductor, or missing child.146 137 CMAS NPRM, 22 FCC Rcd at 21981, ¶19; CMSAAC recommendations, § 5.3.3. 138 See AAPC Comments at 5 (“urg[ing] the Commission to accept the recommendations as presented”). 139 AT&T Comments at 9. 140 CellCast Comments at 36. 141 CMSAAC recommendations, § 5.3.2. 142 See CMSAAC recommendations, § 5.3.2.1. 143 The only exception to this conclusion is the Presidential alert, which will be transmitted regardless of content provided it satisfies the 90 character limit. 144 Id. 145 CMSAAC recommendations, § 5.3.3. 146 Id. Federal Communications Commission FCC 08-99 23 Accordingly, we find that law enforcement authorities should have the ability to formulate unique message text for the dissemination of AMBER Alerts via the CMAS. We envision that such free text messages would be presented to the Alert Gateway in a free text CAP field. In the event of a Presidential Alert, we agree with the CMSSAC that, until such time as electing CMS providers are able to transmit messages longer than 90 characters, the Alert Gateway may employ a generic statement such as “The President has issued an emergency alert. Check local media for more details.”147 4. Geo-targeting CMAS Alerts 48. The CMSAAC recommended that “to expedite initial deployments of CMAS an alert that is specified by a geocode, circle or polygon” should “be transmitted to an area not larger than the CMS [provider’s] approximation of coverage for the county or counties with which that geocode, circle, or polygon intersects.”148 Based on the substantial record before us and for the reasons stated below, we require electing CMS providers to geographically target (geo-target) alerts accordingly. We note that radio frequency (RF) propagation areas for some paging systems and cell sites may exceed a single county, and we will permit geo-targeting that exceeds county boundaries in these limited circumstances. 49. Congress recognized the importance of geo-targeting alerts in the WARN Act. Specifically, in section 604 of the WARN Act, Congress directed the Under Secretary of Homeland Security for Science and Technology, in consultation with the National Institute of Standards and Technology (NIST) and the FCC, to establish a research program for “developing innovative technologies that will transmit geographically targeted emergency alerts to the public.”149 The Commission stands ready to work with DHS and NIST to facilitate this important undertaking.150 We fully expect that as more refined and cost effective geo-targeting capabilities become available to electing CMS providers, they will voluntarily elect to target alerts more granularly. Several CMS providers have indicated their intention to geo-target alerts below the county level and we strongly encourage them to do so.151 As T-Mobile notes, electing CMS providers should be free to target more specifically, subject to the liability protections of the WARN Act.152 50. In the CMAS NPRM, we sought comment on what level of precision the Commission should require for geo-targeting,153 considering the CMSAAC’s recommendation for county-level geo-targeting.154 The CMSAAC recognized “that it is the goal of the CMAS for CMS providers to be able to deliver geo-targeted alerts to the areas specified by the Alert 147 Id. 148 CMSAAC recommendations, § 5.4. 149 WARN Act, § 604(b)(2). 150 The CMSAAC recommends that we encourage DHS to establish a program under section 604 to develop geo- targeting technologies. CMSAAC Recommendations, § 5.4. 151 See, e.g., Alltel Comments at 4-5. 152 T-Mobile Comments at 17. 153 CMAS NPRM, 22 FCC Rcd at 21982 ¶¶ 21-22. 154 CMSAAC recommendations, § 5.4. Federal Communications Commission FCC 08-99 24 Initiator.”155 Based upon current capabilities and to expedite initial deployments, the CMSAAC recommended targeting “an area not larger than the CMS [provider’s] approximation of coverage for the county or counties with which [a transmitted] geocode, circle, or polygon intersects.”156 The CMSAAC recommended that providers should be allowed (but not required) to deliver alerts to areas smaller than a county, using Geographic Names Identification System (GNIS) codes, polygon, or circle information to identify a predefined list of cell sites/paging transceivers within the alert area.157 51. Several parties however urge us to mandate sub-county targeting. Alert Systems claims that disaster managers often require greater geographic granularity than that permitted by CAP and the CMSAAC recommendations.158 Purple Tree Technologies asserts that sub-county targeting is “possible with cell broadcast,” and that there are few technical hurdles preventing granular alerts.159 Acision and CellCast both contend that cell broadcast technology would allow for targeting to the individual cell level.160 DataFM claims its technology could target “specific geographic areas without regard to the location of its transmitters.”161 52. The National Emergency Number Association (NENA) favors targeting smaller areas, noting that some counties are very large and that alert originators often need to target precisely.162 NENA asserts that targeting messages to the block level (similar to emergency telephone notification systems) would be “ideal,” but recognizes this is not possible.163 The CAPUC argues that county targeting would be overbroad for most emergencies, and urges ZIP- code level targeting.164 We note that there are more than 40,000 active ZIP codes in the United States, and many of these are assigned to specific addresses.165 The CAPUC does not explain how ZIP code targeting could be implemented.166 155 Id. Systems used by Alert Initiators may allow them to define an alert area on a map. For example, the defined alert area could include the projected path of a tornado or an event that encompasses a portion of an urban area. 156 Id. at § 5.4. The CMSSAC recommended that if a geocode, polygon, or circle is not transmitted with a non- presidential alert, the “Alert Gateway” should reject the message and return an error to the originator. Id. at App. B, § 10.3.2.22. 157 CMSAAC Recommendations, § 10.3.2. 158 Alert Systems Comments at 17, 18. 159 Purple Tree Comments at 2, 11. We reject Purple Tree Technologies’ suggestion that polygon information should have priority over geocode information, which would be contrary to the CMSAAC Recommendations at § 5.3.1. 160 Acision Comments at 6-7; CellCast Comments at 38-39. Westchester County, New York also supports the use of cell broadcast technology for sub-county targeting. See Westchester County Comments at 2, 3. 161 DataFM Comments at 12. 162 NENA Comments at 2. 163 Id. 164 CAPUC Comments at 13-15. But see NTCA Reply Comments at 4 (“The Commission should decline to follow the CAPUC’s suggestion and should, instead, adhere to the CMSAAC’s recommendation that emergency service alerts be geo-targeted and delivered no lower than the county-wide size area.”). 165 See Census 2000 U.S. Gazetteer Files, available at http://www.census.gov/geo/www/gazetteer/places2k.html. 166 We also note that New York City, which did not file comments, previously expressed concern that alerts should be targeted more precisely than county-level. See CMAS NPRM, 22 FCC Rcd at 21982, n.40. Federal Communications Commission FCC 08-99 25 53. The weight of the record supports county-level targeting as recommended by the CMSAAC. CTIA, TIA and 3G Americas urge us to implement county-level targeting, with optional granularity, to encourage expeditious deployment of alerting capabilities.167 T-Mobile agrees that electing CMS providers should not be not required to target alerts to areas smaller than a county, noting that given current technological limitations, many carriers would be unable to achieve more specificity.168 Alltel also supports county-level targeting, but states that it intends to target more granularly.169 54. MetroPCS notes that for smaller targeting areas, electing CMS providers would have to more precisely control the delivery of messages by the base stations serving a given targeted area than is currently economically feasible.170 Similarly, The National Telecommunications Cooperative Association (NTCA) states that requiring electing rural CMS providers to send alerts to sub-county areas may be too expensive and may reduce the incentive to participate in the CMAS.171 The American Association of Paging Carriers (AAPC) opposes county-level targeting, noting that it may not be feasible for some paging providers to confine alerts to the county level, and that they would target alerts to the extent permitted by their networks.172 55. Based on the foregoing, and subject to the limited exception discussed below, we conclude that it would be premature for us generally to require targeting of alerts more precisely than the county level. We specifically note that county-level targeting is consistent with the current practices of the National Weather Service, which is expected to originate many CMAS alerts. While some commenters argue that cell broadcast and perhaps other technologies could support more granular targeting,173 the record indicates that not all CMS providers may employ cell broadcasting for their delivery of CMAS. Further, while several vendors urge us to mandate sub-county targeting,174 at this point we find that the public interest is best served by enabling participating CMS providers to determine which technologies will most efficiently and cost effectively allow them to target alerts more precisely than the county level. 56. Accordingly, we generally require CMS providers that elect to participate in the CMAS to geographically target emergency alerts to the county level. In adopting this rule, we recognize the concerns of many CMS providers that face technical limitations on their ability to geo-target alerts to areas smaller than a county. In those limited circumstances where the propagation area of a paging system or cell site exceeds a single county, we will permit the RF signal carrying the alert to extend beyond a county’s boundaries. Electing CMS providers may 167 CTIA Comments at 7, 8; TIA Comments at 3, 4; 3G Americas Comments at 9. 168 T-Mobile Comments at 17. 169 Alltel Comments at 4-5. 170 MetroPCS Comments at 4-5. 171 NTCA Reply Comments at 4. 172 AAPC Comments at 7. 173 See, e.g., Purple Tree Comments at 11, CAPUC Comments at 13-15, NENA Comments at 2, Alert Systems Comments at 17-18. 174 See generally Acision Comments at 6-7; Alert Systems Comments at 17, 18; CellCast Comments at 38-39; DataFM Comments at 12; Purple Tree Comments at 2, 11. Federal Communications Commission FCC 08-99 26 determine which network facilities, elements, and locations will be used to transmit alerts to mobile devices. Regarding the CMSAAC recommendation that, until such time as emergency alerts can be delivered to areas smaller than a county in real-time (i.e., dynamic geo-targeting), certain urban areas with populations of greater than 1 million or with specialized alerting needs be identified for more precise geo-targeting,175 we will address this recommendation once an entity has been identified to provide the Alert Aggregator and Gateway functions. 5. Meeting the Needs of Users, Including Individuals with Disabilities and the Elderly 57. Section 603(b)(3)(F) of the WARN Act required that the CMSAAC include representatives of national organizations representing people with special needs, including individuals with disabilities and the elderly.176 Because the WARN Act directed the CMSAAC to submit recommendations to the Commission “as otherwise necessary to enable electing CMS providers to transmit emergency alerts to subscribers,”177 the CMSAAC concluded, and we agree, that Congress intended to include the elderly and those with disabilities among the class to which electing CMS providers are to deliver alerts. Accordingly, we conclude that CMAS access to those with disabilities and the elderly falls within our obligation under section 602(a) of the WARN Act, and thus seek to ensure that commercial mobile alerts are accessible to all Americans, including individuals with disabilities and the elderly. 58. The CMSAAC recommended that the needs of individuals with disabilities and the elderly be addressed by, inter alia, the inclusion of a common audio attention signal, and a common vibration cadence, on devices to be used for commercial mobile alerts.178 The CMSAAC recommended that both functions be distinct from any other device alerts and restricted to use for commercial mobile alerting purposes. 179 The CMSAAC further noted that these features would benefit not only individuals with disabilities and the elderly, but also subscribers more generally. 59. For devices with polyphonic capabilities, the CMSAAC recommended that the audio attention signal should consist of more than one tone, in a frequency range below 2 kHz and preferably below 1 kHz, combined with an on-off pattern to make it easier for individuals with hearing loss to detect.180 For devices with only a single frequency capability, the CMSAAC recommended an audio attention signal below 2 kHz.181 The CMSAAC also recommended that the unique vibration cadence should be noticeably different from the default cadence of the handset.182 The CMSAAC further recommended that if a device includes both the audio and 175 CMSAAC Recommendations, § 5.4. 176 WARN Act, § 603(b)(3)(f). 177 WARN Act, § 603(c)(7). 178 CMSAAC recommendations, § 5.5.2.1. 179 Id. 180 Id. 181 Id. 182 Id. Federal Communications Commission FCC 08-99 27 vibration functions, simultaneous activation of both functions should not be required and that configuration should be determined by end users.183 60. In the CMAS NPRM, we sought comment on the CMSAAC recommendations, including any technical or accessibility requirements that we should adopt to ensure that commercial mobile alerts will be received by individuals with disabilities and the elderly.184 We asked whether attention signals should be required for all users.185 We also noted that the CMSAAC recommended that alert initiators use clear and simple language whenever possible, with a minimal use of abbreviations and the ability to recall alert messages for review—and sought comment on these recommendations within the context of accessibility for individuals with disabilities and the elderly.186 61. Nearly all commenting parties support the CMSAAC’s recommendations for addressing the needs for individuals with disabilities and the elderly. AT&T, for example, states that adoption of the CMSAAC’s recommendations for a common audio signal and vibration cadence will “allow for the immediate identification of emergency alerts” and foster “the widest possible distribution of alerts” to the public.187 Alert Systems likewise notes that “[u]rgency coding of messages is vital,”188 and that caretakers and operators of certain industrial facilities in particular “need unique alert tone patterns/amplitudes to quickly reprioritize activities.”189 62. The Wireless Rehabilitation Engineering Research Center for Wireless Technologies (Wireless RERC) supports adoption of a common audio attention signal, and recommends that we adopt the existing 8-second EAS attention signal for all users, asserting that it provides the necessary period of time to alert individuals with hearing disabilities.190 The Wireless RERC also supports adoption of a common vibration cadence, and states that electing CMS providers should provide clear instructions on the alert capabilities of their devices, including labels identifying mobile devices suitable for persons with audio and visual disabilities.191 AAPC supports the CMSAAC recommendations, but states that legacy devices should not be required to support such functions.192 CAPUC adds that although the CMSAAC was required to issue recommendations on wireless alerts exclusively, the Commission should consider ensuring interoperability with wireline devices for individuals with disabilities and the elderly, noting that some such users may not have access to wireless devices.193 DataFM notes 183 Id. 184 CMAS NPRM, 22 FCC Rcd at 21982-83, ¶ 23. 185 Id. 186 Id. 187 AT&T Comments at 15. 188 Alert Systems Comments at 18. 189 Id. 190 Wireless RERC Comments at 11. 191 Id. at 11-12. Wireless RERC also states that CMS providers should notify those subscribers whose mobile devices require upgrading to support CMAS. Id. at 12. 192 AAPC Comments at 7-8. 193 Id. at 18. Federal Communications Commission FCC 08-99 28 that it currently has equipment for text-to-speech for the blind and strobe light warnings for the deaf, and would employ audio alerts and vibration alerts for portable devices.194 63. Although there is near unanimous support of the CMSAAC’s recommendations for addressing the needs of individuals with disabilities and the elderly, several parties argue that no additional requirements are necessary. MetroPCS claims that the handsets that will be used to receive mobile alerts are already subject to disability access requirements, and any additional requirements may raise costs thereby discouraging CMS provider participation.195 CellCast argues that no changes to CMS provider networks should be required, noting that some mobile devices can be configured to enable the elderly or blind to hear an audio conversion of the message using text-to-speech technologies.196 64. We agree with the majority of those commenting and the CMSAAC that it is vital that we ensure access to commercial mobile alerts by individuals with disabilities and the elderly. We disagree with the premise articulated by some commenters that merely because some device manufacturers already include accessibility features for receipt of mobile alerts, no requirements are needed to ensure access to mobile alerts for individuals with disabilities and the elderly. 65. Accordingly, to address the needs of these user groups and the needs of users more generally, we will require that participating CMS providers include both a common vibration cadence and a common audio attention signal on any device offered to the public for reception of commercial mobile alerts.197 Specifically, as the CMSAAC recommended, we specify a temporal pattern for the audio attention signal of one long tone of two (2) seconds, followed by two short tones of one (1) second each, with a half (0.5) second interval between the tones.198 We will also require that the entire sequence be repeated twice with a half (0.5) second interval between repetitions.199 For devices with polyphonic capabilities, we adopt the CMSAAC’s recommendation that the audio attention signal consist of the two EAS tones (853 Hz and 960 Hz). For devices with a monophonic capability, we will require that a universal audio attention signal be of 960 Hz (the higher frequency EAS tone). 66. We also seek to facilitate recognition of alerts for individuals that may have a hearing disability (or who may have muted the audio attention signal on their device), and therefore adopt the same temporal pattern for the vibration cadence as the CMSAAC recommended that the Commission specify for the audio attention signal. We strongly 194 DataFM Comments at 12-13. 195 MetroPCS Comments, citing 47 C.F.R. § 20.19. 196 CellCast Comments at 43-44. 197 The CMSAAC recommendations state that “[a] unique vibration cadence (if supported by the mobile device) should be provided as well as a unique audio attention signal.” CMSAAC Recommendations at § 5.5.2. To the extent that this language implies that CMAS-capable mobile devices do not have to supply a unique vibration cadence, we disagree. Rather, we believe that full access by people with hearing disabilities requires vibration capability. Given that most current mobile handsets are capable of programming dedicated audio and vibration ring tones, we do not believe that this requirement represents a significant burden for CMS providers or is inconsistent with the WARN Act. 198 CMSAAC recommendations, § 7.2. 199 Id. Federal Communications Commission FCC 08-99 29 encourage CMS providers to coordinate with device manufacturers to utilize existing technologies to comply with these requirements as soon as possible. 67. We recognize that incorporating capabilities for a common audio attention signal and a common vibration cadence on the many devices that we expect to be offered to the public will take time to develop and implement successfully. However, we believe that assuring full access for all Americans is sufficiently important that equipment may not be considered CMAS compliant unless it includes both the common audio attention signal and the vibration cadence adopted in this Report and Order. Further, both functions must be distinct from any other incoming message alerts and restricted to use for CMAS alerting purposes. Finally, simultaneous activation of both the audio attention signal and vibration cadence is permissible.200 6. Output Mode/Display 68. The CMSAAC issued several recommendations regarding the output mode/display of mobile devices.201 Specifically, the CMSAAC recommended that CMAS- enabled mobile devices should employ display fonts that are easily readable with recognizable characters, citing three typeface examples.202 MetroPCS notes that certain accessibility requirements already apply to CMS providers, and that CMAS-enabled mobile devices will therefore accommodate certain disabilities.203 CellCast adds that the development of mobile devices is highly competitive and flexible enough to meet the needs of all users including those with special needs.204 Although we agree with the CMSAAC that “the goal in font selection is to use easily recognizable characters,”205 we do not want to constrain the ability of CMS providers and manufacturers of devices to implement display modes that they find will best meet the needs of people with disabilities and other users. Accordingly, we do not limit the display of CMAS alerts to a particular font or character set. 69. Text-to-speech (TTS) enabled wireless mobile devices are becoming increasingly common,206 and we strongly encourage all participating CMS providers to offer devices with such capabilities so that blind individuals and those with severe visual impairments can obtain the public safety benefits of commercial mobile alerts. We note that many of the requirements that we adopt today for the first generation of CMAS are intended to enable the provision of text- based alerts to the public. Although we envision that the CMAS will evolve to include audio and video service profiles, we find that at this initial stage of the CMAS, it would be premature to address the CMSAAC’s recommendations regarding output mode/displays for such future service profiles. 200 We agree with the CMSAAC that CMAS compliant mobile devices may include the capability to mute either or both of these features so that they will not be activated upon receipt of an alert. CMSAAC recommendations, § 7.3. 201 See CMSAAC recommendations, § 5.5.2.3. 202 Id., citing Tips for Making Print More Readable, American Foundation for the Blind, available at http://www.afb.org/Section.asp?SectionID=40&TopicID=200&DocumentID=210. 203 MetroPCS Comments at 5, citing 47 C.F.R. § 20.19. 204 CellCast Comments at 43-44. 205 CMSAAC recommendations, § 5.5.2.3. 206 Information regarding TTS is http://www.research.att.com/~ttsweb/tts/faq.php#TechWhat. Federal Communications Commission FCC 08-99 30 7. Message Retransmission 70. We agree with the CMSAAC that alerts should be retransmitted periodically to an affected area until their specified expiration.207 Periodic retransmission of alerts is vital because some individuals, particularly motorists, may enter an alert area after initial transmission of an alert. Others may miss the initial alert because of an ongoing call (as explained below, alerts may not preempt a call in progress),208 or because they had their mobile device turned off or muted when an alert was first transmitted. As the CMSAAC noted, the optimal frequency of alert retransmission requires a balancing of many factors, including the capabilities of a CMS provider’s delivery technology and end users’ handsets, the number of ongoing active alerts, device battery life, and impacts on network call and data processing. The CMSAAC recommended that each CMS provider should determine how often an alert will be retransmitted based on such considerations.209 We agree with this assessment and adopt this recommendation as reasonable for the initial implementation of the CMAS. As the system is deployed, we may wish to revisit the issue to see if a consistent, industry-wide alert retransmission interval would be more appropriate. 8. Multi-Language CMAS Alerting 71. The WARN Act required the CMSAAC to submit recommendations to the Commission regarding “the technical capability to transmit emergency alerts by electing commercial mobile providers to subscribers in languages in addition to English, to the extent practical and feasible.”210 In the CMAS NPRM, we sought comment on the technical feasibility of providing commercial mobile alerts in languages in addition to English,211 including how the provision of alerts in multiple languages could affect the generation and distribution of messages on a local, state, and national level.212 Based on the record before us, we find that it would be premature to require CMS providers to transmit alerts in languages in addition to English. As explained below, we agree with the CMSAAC and those commenters that state that further technical study is needed to enable the provision of alerts in multiple languages. 72. The CMSAAC provided recommendations regarding multi-language alerting in section 5.7 of its report. The CMSAAC specifically “recognized that there is a strong desire for the CMAS to support Spanish in addition to English,” but found that supporting multiple languages in the first generation of CMAS could adversely impact system capacity and increase message latency.213 It noted that while Spanish and English would cover 99 percent of all U.S. households, there are more than 37 languages in the United States that exceed 1 percent of households on a local level. 214 The CMSAAC stated that delivering CMAS alerts in these 207 See CMSAAC recommendations, § 5.6. 208 See infra ¶ 80. 209 See CMSAAC recommendations, § 5.6. 210 WARN Act, § 603(c)(4). 211 CMAS NPRM, 22 FCC Rcd at 21983, ¶ 24. 212 Id. 213 CMSAAC recommendations, § 5.7. 214 Id. Federal Communications Commission FCC 08-99 31 languages would require mobile devices capable of supporting at least 16 different character sets.215 The CMSAAC also stated that some languages require two bytes per character rather than one byte per character for English, thereby further limiting message length.216 The CMSAAC found that the technical feasibility of providing alerts in languages in addition to English is a highly complex issue requiring further study. Finally, the CMSAAC noted that the CMAS architecture can support language extensions and recommended that this capability be reserved for future study.217 73. Several parties disagree that the technical feasibility of providing alerts in languages in addition to English requires further study, and urge us to mandate the provision of alerts in multiple languages now. The CAPUC notes that “roughly 30.1 percent of California’s population has limited English proficiency,”218 and that the State “uses different languages for different types of communications . . . [including] Spanish, Cantonese, Mandarin, Tagalog, Vietnamese, Korean, Farsi, Arabic, and Hmong.”219 The CAPUC asserts “that various commercial alert service providers represent that they can provide alerts in six different languages,”220 but does not identify these service providers. There is no evidence in the record before us however of any CMS provider having the current capability to deliver alerts in six different languages, and we therefore cannot adopt CAPUC’s request that we require transmission of alerts in a minimum of six languages.221 74. CellCast and One2many also urge us to implement multiple language alerting. CellCast notes that pending standards under the ITU for Message Indicators (MIs) can facilitate either the dedication of discrete MIs for specific languages, or the rejection of messages in undesired languages via the message preamble.222 CellCast suggests that such standards would provide clear direction for international harmonization of emergency alerting systems and handsets.223 CellCast further argues that the potential latency of multiple messages in sequential languages would be indiscernible to a mobile user and should not impact that user’s ability to react to an emergency.224 CellCast claims that the delivery of multi-language alerts would not add any new burden on the Alert Aggregator or the CMS provider, and would not require any development of new technology.225 One2many states that there are numerous “channels,” or 215 Id. 216 Id. 217 Id. 218 CAPUC Comments at 19. 219 Id., n.16. 220 Id. at 20. 221 See id. at 19. 222 CellCast Comments at 46. 223 CellCast Reply Comments at 20. 224 CellCast Comments at 47-48. 225 CellCast Reply Comments at 22-23. Federal Communications Commission FCC 08-99 32 Message Identifiers, available in a cell broadcast.226 According to One2many, end users can activate their phones to receive messages on the channel number that matches their language.227 75. By contrast, most parties in this proceeding concur with the CMSAAC that further study of multiple language alerting is necessary. CTIA, for example, states that we should not require electing CMS providers to transmit alerts in multiple languages because of limitations in providers’ existing air interfaces, handset character sets, and traffic overflow.228 Regarding the varying air interfaces, Alltel concurs with the CMSAAC that transmitting multi- language alerts is not technically feasible for CDMA systems, subject to future review as technology improves.229 According to Alltel, GSM can support multiple channels for simultaneous broadcast and discrete channels could be dedicated to different languages.230 Alltel explains that CDMA lacks this capability and would require sequential broadcasts of alerts in multiple languages with the potential for unacceptable latency between broadcasts of the same language while alerts in multiple languages are sequentially broadcast.231 76. With respect to character set limitations in mobile devices, MetroPCS states that most handsets currently marketed in the United States use the Latin alphabet and would not support other languages—and that adding such capabilities would create substantial burdens on electing CMS providers and manufacturers, while increasing the costs of handsets to consumers.232 The American Association of Paging Carriers similarly explains that parallel alerts in languages other than English would threaten network congestion, and complicate subscriber device designs and capabilities.233 T-Mobile adds that a multi-language requirement would impede CMAS deployment, and that until the technology improves to facilitate multiple languages, non-English speaking users could be prompted by an English alert to turn to sources in their respective languages for further information.234 77. Several parties, including AT&T, recommend that the Commission initially require alerts only in English, but also develop a national plan that provides federal, state, and local alert initiators with clear guidance on how alert initiators must craft multi-language alerts that reach the electing CMS Provider Gateways in a standardized format ready for end-user delivery without translation.235 The CAPUC, which advocates mandatory multi-language alerting, urges the Commission to examine whether latency or delivery concerns could be 226 One2many Comments at 7. 227 Id.; see also DataFM Comments at 13. 228 CTIA Comments at 9-10; CTIA Reply Comments at 7-9. 229 Alltel Comments at 5-6. 230 Id. at 5. 231 Id.; Alltel Reply Comments at 4; see also TIA Comments at 8-10. 232 MetroPCS Comments at 5; cf. Alert Systems Comments at 18-19. Alert Systems argues that regulatory mechanisms for alternate languages are unnecessary because the system’s development is really only limited by the font sets of the receiving devices and by the ability of disaster management agencies to prepare warnings in other languages. Id. 233 AAPC Comments at 8. 234 T-Mobile Comments at 13-14. 235 AT&T Comments at 15-16; CTIA Reply Comments at 7-9. Federal Communications Commission FCC 08-99 33 resolved if language receipt were part of a pre-subscription process.236 The Wireless RERC asks that we encourage providers serving non-English speaking users to install software that will automatically translate English emergency messages into other languages, especially given the potential delay caused by an alert originator having to send out messages in multiple languages.237 These parties’ insightful comments as well as those discussed above underscore that electing CMS providers face many technical challenges as they seek to implement alerting in languages in addition to English. Accordingly, we conclude that further study is needed to develop capabilities for providing alerts in multiple languages, and do not require provision of alerts in any language other than English at this time. We encourage the wireless industry and the public safety community to expeditiously develop and implement capabilities to deliver alerts in languages in addition to English. 9. Roaming 78. We agree with the CMSAAC and the majority of commenting parties that the public interest will be served by requiring participating CMS providers to support CMAS alerting when subscribers are receiving services through roaming.238 As discussed further below, we find that adopting such a requirement is consistent with our responsibility under the WARN Act to enable commercial mobile service alerting,239 as well as our duty under Executive Order 13407 to “adopt rules to ensure that communications systems have the capacity to transmit alerts and warnings to the public as part of the public alert and warning system.”240 79. In the Automatic Roaming Order, the Commission found that “consumers have come to expect seamless wireless service wherever they travel within the United States and, ultimately, this will be achieved through automatic roaming.”241 Thus, as a general matter, mobile device users will anticipate that the alerting features and services available to them in their home market will be available when roaming. Under the rules we adopt today, when a subscriber receives services pursuant to a roaming agreement and the operator of the roamed upon network is a participating CMS provider, the subscriber will receive alerts messages, 236 Id. 237 Wireless RERC Comments at 12. T-Mobile, however, criticizes this suggestion in its reply comments, noting that such an existing technology is not identified in the record, and that it is against the CMSAAC’s goal of uniform, error-free messaging to allow multiple carriers to create their own versions of alerts in various languages. T-Mobile Reply Comments at 7-8. T-Mobile contends that the only means for transmitting multi-language alerts is for the Alert Aggregator to send messages in multiple languages, as the CMSAAC recommends. Id. at 8. 238 CMSAAC recommendations, § 5.9. 239 WARN Act, § 602(a). 240 Executive Order 13407, § 3(b)(iii). 241 Reexamination of Roaming Obligations of Commercial Mobile Radio Service Providers, WT 05-265, Report and Order and Further Notice of Proposed Rulemaking, 22 FCC Rcd 15817, 15855, ¶76 (2007). We note that the scope of the Commission’s automatic roaming requirement is applicable to CMRS carriers “if such carriers offer real-time two-way switched voice or data service that is interconnected with the public switched network and utilizes an in-network switching facility that enables the carrier to re-use frequencies and accomplish seamless hand- offs of subscriber calls.” See 47 C.F.R. § 20.12(a)(2). The automatic roaming requirement is also applicable to the provision of push-to-talk and text-messaging service by CMRS carriers. Id. Federal Communications Commission FCC 08-99 34 provided the subscriber’s mobile device is configured for and technically capable of receiving alert messages from the roamed upon network.242 10. Preemption of Calls in Progress 80. The CMSAAC recommended that CMAS alerts not preempt ongoing voice or data sessions.243 We agree with this recommendation. We believe that it would be contrary to the public interest if alert messages were to preempt certain active voice or data sessions. During a crisis, such as a terrorist attack, many individuals will be seeking emergency aid related to the actual event and other emergencies. In either circumstance, the public would be ill served if their calls for urgent aid were summarily preempted. In light of this, we will require that any device marketed as “CMAS compliant” must not permit an alert to preempt an ongoing call. D. Service Profiles 81. In its recommendations, the CMSAAC introduced the concept of technology- neutral service profiles for emergency alerts, each containing, for example, information on maximum payload and displayable message size.244 The CMSAAC further recommended specific service profiles for: (a) Text; (b) Streaming Audio (future capability); (c) Streaming Video (future capability); and (c) Downloaded Multimedia Profile (future capability), and provided general recommendations and conclusions for each. In the CMAS NPRM, we sought comment on the service profiles recommended by the CMSAAC. We agree with those commenters who argue that we should adopt the CMSAAC’s recommendation that text-only alerts are appropriate for an initial system.245 Because we believe that it would be premature and not consistent with our obligations under section 602(a) of the WARN Act to adopt standards and requirements for technologies that are still under development, this order will not address future technologies such as streaming audio, video and downloadable multimedia. Rather, this order will only address CMSAAC recommended profiles for text. 82. As part of the text profile, the CMSAAC recommended a maximum displayable message size of 90 characters. We sought comment on this recommendation in the CMAS NPRM.246 Several commenters support the CMSAAC’s recommendation. For example, AT&T states that, “given the current technical limitations in delivering emergency alerts, during the nascent stages of the CMAS the Commission should limit alerts to 90 characters . . .”247 Motorola supports this view and notes that inclusion of additional information and characters beyond 90 characters will strain the network, causing few people to receive the alert.248 AAPC states that the 90 character limit strikes an appropriate balance between complexity and a 242 We will defer consideration of any subscriber notification requirements related to CMAS roaming to our forthcoming order addressing the WARN Act’s requirements under section 602(b) for CMAS provider elections to support CMAS. 243 CMSAAC recommendations, § 7.3. 244 CMSAAC recommendations, § 6 (Service Profiles). 245 See, e.g. Purple Tree Technology Comments at 9, AT&T Comments at 10. 246CMAS NPRM, 22 FCC Rcd at 21980-81, ¶15. 247 AT&T Comments at 8 248 Motorola Comments at 3. Federal Communications Commission FCC 08-99 35 reasonably constructed CMAS.249 Other commenters raised concerns that a 90 character limit would not provide sufficient information to subscribers about emergencies. For example, CellCast states in their comments that 90 characters alone is insufficient to convey a complete alert to mobile devices.250 Furthermore, one commenter stated that the “character count recommendations are reasonable for display of ‘basic’ warnings but CMSAAC recommendations should accommodate supplemental and verbose message formats.”251 83. We conclude that, at this initial stage, adoption of a 90 character limit serves the public interest. We agree with commenters such as MetroPCS that a 90 character limit will allow all systems to transmit the message with minimal change, and that 90 characters is an effective limit to allow the message to be delivered and actually be read.252 As the CMSAAC concluded and the Wireless Rehabilitation Engineering Research Center (WRERC) notes, the 90 character text limit of any CMAS alert is reasonable because the CMAS alert is intended to get the attention of a person. The person can then seek out other media for confirmation of the alert and more information.253 84. The CMSAAC also recommended that where the alert coming into the Alert Gateway contains a link to an Internet web site (or URL) as a resource element, the Alert Gateway would retrieve any file specified by the URL and deliver that file to the CMS Provider Gateway. This is a different issue from the URL in free text issue discussed above, because it implicates the manner in which the alert is sent to the CMS Provider Gateway, as opposed to the actual content of the alert itself. We agree with the CMSAAC that CMS provider networks do not have the resources to process alerts with internet links. Further, URLs may link the CMS Provider Gateway to untrusted Internet sites that could fall outside the security requirements that the electing CMS providers have indicated are an essential element of the CMAS. Accordingly, in the CMS provider profile, no alerts with internal URLs may be accepted.254 Rather, related files or other resource elements must be provided separately by the Alert Gateway to the CMS Provider Gateway. 85. We also adopt the CMSAAC observation that the CMAS profiles will not be able to accommodate real-time content, including a Presidential alert, even in text format. We believe that the CMSAAC has given sufficient indication of the limits of current CMS provider architecture to support this conclusion. Currently, the only real-time alert that could potentially be provided to the CMAS is the Presidential alert (Emergency Alert Notification or EAN). In the event that such a significant event were to occur, all broadcast media would be carrying the message, and as the Wireless RERC recommends, instructing the public to tune to their local 249 AAPC Comments at 5. 250 See CellCast Comments at 28. 251 See Kendall Post of Alert Systems, Inc. at 15. 252 Metro PCS Comments at 3. 253 Wireless RERC Comments at 8. 254 The only exception to this is the Presidential alert, which will be transmitted provided it meets the 90-character limit. Federal Communications Commission FCC 08-99 36 radio and television station and other mass media is the best option for obtaining additional emergency information.255 86. The text profiles we adopt today are reflected in table below: Text Profile Service Profile: Text_Universal_Service_Profile Attribute Name Attribute Definition Note Purpose Common denominator for text messages Maximum Payload Size 120 bytes Size is estimated Maximum Displayable Message Size 90 characters for an English language CMA encoded with 7-bit encoding Languages other than English, or coding other then 7-bit coding, will result in a change to the maximum number of characters supported Data Coding Scheme UTF-8 as defined in IETF RFC-3629 The text provided over the C interface is provided in UTF-8 format which is capable of supporting text in English and other languages. It is the responsibility of the CMS Provider Gateway to translate to any character format encoding required by the CMS provider selected delivery technology. E. Security for CMAS Alerts 87. The CMSAAC recommended a specific Alert Aggregator and Alert Gateway Trust Model to assure the security, authentication and authorization of alerts from the Alert initiator to the CMS Provider Gateway. The CMSAAC also recommended security requirements for communications across the “C” interface between the Alert Gateway and CMS Provider Gateways and within each CMS provider’s network. For example, the CMSAAC recommended that communications across the “C” interface be IP based. According to the CMSAAC, the security of the Reference Point C interface should be based upon standard IP security mechanisms such as VPN tunnels and IPSEC functionalities.256 88. We find that an IP-based communications across the “C” interface serves the public interest because it would enhance the security of the CMAS. Accordingly, we adopt the CMSAAC’s recommendation. We disagree with Purple Tree Technologies’ concerns that the protocols put forth are insufficient to provide the security required, and that a higher layer security protocol is necessary over the “C” interface between the Alert and CMS Provider Gateways.257 Rather, we agree with Verizon Wireless, which in its Reply Comments rejects such a need.258 As Verizon Wireless correctly points out, under the CMAS Reference Architecture, which we have adopted in this Order, the need for higher layer security protocols exists only as an element of the “Trust Model,” which addresses the linkage between the Alert Gateway and 255 Wireless RERC Comments at 9. 256 See CMSAAC recommendations, § 8.3 257 Purple Tree Technologies Comments at 6. 258 See Verizon reply Comments at 5. Federal Communications Commission FCC 08-99 37 alert initiators.259 By the time the Alert Gateway hands off a particular alert to the CMS Provider Gateway, any necessary authentication and authorization has been completed, thus obviating the need for a higher level security layer over the “C” interface. 89. The CMSAAC recommended that the security at Reference Points D and E be based upon CMS provider policies and upon the capabilities of the CMS provider selected delivery technologies. No commenter opposes this recommendation, and we believe that the recommendation is consistent with the technologically neutral policy of this order and is consistent with section 602(a) of the WARN Act which requires that we adopt technical requirements necessary to facilitate emergency alert capabilities of CMS providers. Accordingly, we adopt this recommendation of the CMSAAC. F. CMAS Reliability and Performance 90. The CMSAAC made general recommendations concerning CMAS system performance requirements. Most requirements are prospective observations and recommendations. Major ones include: · Alert Gateway capacity. Based on historical data, the CMSAAC made certain predictions concerning Alert Gateway performance requirements, including the capability to monitor system utilization for capacity planning purposes, and to temporarily disable and buffer CMAS alert traffic in the event of an overload. · Assessing latency in alert delivery. The CMSAAC stated that such an assessment would be difficult to make prior to deployment, but notes certain relevant factors, including; mobile device battery life impact, call processing impact; capabilities of the delivery technology; message queues; number of languages; number of targeted cell sites/paging transceivers for the alert area; and any geo-targeting processing. · End to end reliability. The CMSAAC recommends that the CMAS end-to-end reliability technology meet telecom standards for highly reliable systems, but notes that the over-all reliability of CMAS is unpredictable because RF transmissions can be subject to noise and other interference or environmental factors; the capabilities of the cellular environment are not predictable especially in a disaster environment; the subscriber may be in a location that does not have any RF signal; and the subscriber’s mobile device may not have any remaining power. 91. In order to assure the reliability and performance of this new system, the CMSAAC recommended procedures for logging CMAS alerts at the Alert Gateway and for testing the system at the Alert Gateway and on an end-to-end basis. Because this presumes the existence of an entity acting in the role of Alert Aggregator/Gateway, we cannot adopt rules in this area at this time.260 259 Id. 260 See supra, ¶¶ 15-18. Federal Communications Commission FCC 08-99 38 G. Timeline for Implementation of Technical Requirements, Standards and Protocols. 92. In its recommendations, the CMSAAC proposed a specific timeline for the implementation of the CMAS. According to the CMSAAC, it would take a minimum of 24 months from the date by which CMS providers must elect to participate in the CMAS under section 602(b)(2)(A) of the WARN Act) to deploy the CMAS.261 The CMSAAC proposed deployment timeline was based upon the assumptions that (1) the CMSAAC recommendations contained within this document are accepted without any major technical changes and (2) the government documentation and deliverables are available at the milestone dates indicated on the timeline. In this regard, the CMSAAC also assumed that the requirements, development, and deployments of the Alert Gateway and Alert Aggregator would align with the CMS provider developments to allow for testing during the development process and prior to CMAS deployments. The CMSAAC recommended timeline assumed that Federal Government interface specifications would be available in January, 2008, 10 months before CMAS development and testing was to begin. 93. At the outset we note that the majority of commenters that addressed the issue supported the CMSAAC’s proposed deployment timeline.262 Further, in its comments, FEMA asked the Commission not to adopt an effective date for these rules until all legal issues regarding the Federal government’s role in the CMAS have been identified and resolved. In making this request, FEMA provided no indication as to when it believes such issues may be resolved.263 94. Issues related to the CMSAAC proposed timeline fall under the election provisions of section 602(b) of the WARN Act, and so are not strictly within the purview of this initial technical order that complies with section 602(a). However, we agree with the CMSAAC that the Alert Aggregator and Alert Gateway must be in place in order for CMS providers to complete development of the CMAS and to begin receiving and transmitting emergency alerts. 95. Accordingly, CMS providers must comply with the technical rules we adopt today no later than 10 months from the date of announcement of an entity to provide the Alert Aggregator and Alert Gateway functions.264 This time period is consistent with the 10 months the CMSAAC proposed timeline indicates would elapse between the availability of the 261 CMSAAC recommendations, § 12.2. 262 See n.20, supra. 263 FEMA Comments at 2. 264 We state, infra at ¶ 94, that this Report and Order shall become effective 30 days after publication in the Federal Register except that the new information collection requirements contained in these rules will not become effective prior to OMB approval. However, the rules themselves specifically state that electing CMS providers must comply no later than 10 months from the date of announcement of an entity to serve the Alert Aggregator and Alert Gateway functions. This is similar to Commission’s adoption of rules requiring all EAS Participants to be able to receive CAP formatted EAS alerts no later than 180 days after FEMA publishes the technical standards and requirements for such FEMA transmissions. See Review of the Emergency Alert System, 22 FCC Rcd 13275, 13310 and Appendix C; see also 47 C.F.R. § 11.56. That Order also became effective 30 days after publication in the Federal Register, except that new or modified information collections did not become effective prior to OMB approval. Federal Communications Commission FCC 08-99 39 Aggregator/Gateway interface design specification and the beginning of CMAS development and testing. We believe that this will give the government and industry stakeholders sufficient time to the federal government's role. It will also give electing CMS providers adequate time to come into compliance with the rules adopted herein.265 IV. PROCEDURAL MATTERS A. Final Regulatory Flexibility Act Analysis 96. As required by section 603 of the Regulatory Flexibility Act (RFA), 5 U.S.C. § 604, the Commission has prepared a Final Regulatory Flexibility Analysis of the possible impact of the rule changes contained in this Report and Order on small entities. The Final Regulatory Flexibility Act analysis is set forth in Appendix B, infra. The Commission’s Consumer & Government Affairs Bureau, Reference Information Center, will send a copy of this Report and Order, including the Final Regulatory Flexibility Act Analysis, to the Chief Counsel for Advocacy of the Small Business Administration. B. Final Paperwork Reduction Act of 1995 Analysis 97. This Report and Order may contain new information collection requirements subject to the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. If the Commission determines that the Report and Order contains collection subject to the PRA, it will be submitted to the Office of Management and Budget (OMB) for review under section 3507(d) of the PRA at an appropriate time. At that time, OMB, the general public, and other Federal agencies will be 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. C. Congressional Review Act Analysis 98. The Commission will send a copy of this Report and Order in a report to be sent to Congress and the Government Accountability Office pursuant to the Congressional Review Act, see 5 U.S.C. 801(a)(1)(A). D. Alternative Formats 99. Alternative formats (computer diskette, large print, audio cassette, and Braille) are available to persons with disabilities by sending an e-mail to FCC504@fcc.gov or calling the Consumer and Governmental Affairs Bureau at (202) 418-0530, TTY (202) 418-0432. V. ORDERING CLAUSES 100. IT IS ORDERED, that pursuant to sections 1, 4(i) and (o), 201, 303(r), 403, and 706 of the Communications Act of 1934, as amended, 47 U.S.C. §§ 151, 154(i) and (o), 201, 303(r), 403, and 606, as well as by sections 602(a),(b),(c), (f), 603, 604 and 606 of the WARN Act, this Report and Order IS hereby ADOPTED. The rules adopted in this Report and Order shall become effective 30 days after publication in the Federal Register except that the new 265 We note that our adoption of an effective date and compliance deadline have no impact on the WARN Act's requirement that CMS providers notify the Commission whether or not they intend to transmit emergency alerts within 30 days of the Commission's issuance of rules required under section 602(b). See WARN Act, § 602(b). Federal Communications Commission FCC 08-99 40 information collection requirements contained in these rules will not become effective prior to OMB approval.266 266 See supra ¶ 95. Federal Communications Commission FCC 08-99 41 101. IT IS FURTHER ORDERED that the Commission’s Consumer and Government Affairs Bureau, Reference Information Center, SHALL SEND a copy of this Report and Order, including the Final Regulatory Flexibility Analysis, to the Chief Council for Advocacy of the Small Business Administration. FEDERAL COMMUNICATIONS COMMISSION Marlene H. Dortch Secretary Federal Communications Commission FCC 08-99 42 APPENDIX A List of Commenters Comments in PS Docket No. 07-287 Commenters Abbreviation 3G Americas 3G Americas Acision B.V. and One2Many B.V. Acision Alliance for Telecommunications Industry Solutions ATIS Alltel Communications, LLC Alltel American Association of Paging Carriers AAPC America's Emergency Network AEN Association of Public Television Stations APTS AT&T Inc. AT&T Audemat-Aztec Inc. Audemat-Aztec California Public Utilities Commission CAPUC CellCast Technologies, LLC CellCast Cellular Emergency Alert Service Association – US Chapter CEASA-US CTIA – The Wireless Association CTIA DataFM, Inc. DataFM Digital Alert Systems, LLC DAS Ericsson Inc. Ericsson Florida Association of Broadcasters FAB Global Security Systems, LLC Global Interstate Wireless Inc. Interstate Wireless Jacob Westfall Westfall Kendall Post Post Max Mayfield Mayfield MetroPCS Communications, Inc. MetroPCS Mississippi Association of Broadcasters Mississippi Broadcasters Mississippi Emergency Management Agency MS-EMA Mississippi Office of Homeland Security MS-OHS Motorola, Inc. Motorola National Association of Broadcasters NAB National Emergency Numbering Association NENA Nokia Inc. and Nokia Siemens Networks US LLC Nokia Pontotoc County Emergency Management Agency Pontotoc EMA Purple Tree Technologies PTT Rehabilitation Engineering Research Center for Wireless Technologies Wireless RERC Rural Cellular Association RCA Sheriff, Jefferson Davis Parish, Louisiana Sheriff SouthernLINC Wireless SouthernLINC Sprint Nextel Corporation Sprint Nextel Federal Communications Commission FCC 08-99 43 SquareLoop, Inc. SquareLoop Telecommunications Industry Association TIA T-Mobile USA, Inc. T-Mobile Verizon Wireless Verizon Reply Commenters Abbreviation Airadigm Communications - Einstein Wireless Airadigm Alltel Communications, LLC Alltel American Association of Paging Carriers AAPC Association of Public Television Stations APTS AT&T Inc. AT&T CellCast Technologies, LLC CellCast CTIA – The Wireless Association CTIA Cox Radio, Inc. Cox DataFM, Inc. DataFM FEMA, Director, Office of Nat’l Security Coordination FEMA Global Security Systems, LLC Global Interstate Wireless Inc. Interstate Wireless King County, Washington King County Motorola, Inc. Motorola National Telecommunications Cooperative Association NTCA NTI Group, Inc. NTI OnStar Corporation OnStar Rural Cellular Association RCA SquareLoop, Inc. SquareLoop T-Mobile USA, Inc. T-Mobile Verizon Wireless Verizon Ex Parte Commenters Abbreviation American Association of Paging Carriers AAPC AT&T Inc. AT&T CTIA – The Wireless Association CTIA DataFM, Inc. DataFM Global Security Systems, LLC Global National Telecommunications Cooperative Association NTCA OnStar Corporation OnStar Rural Cellular Association RCA Federal Communications Commission FCC 08-99 44 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 in the Notice of Proposed Rulemaking in PSHSB Docket 07-287 (CMAS NPRM). The Commission sought written public comments on the proposals in the CMAS NPRM, including comment on the IRFA. Comments on the IRFA were to have been explicitly identified as being in response to the IRFA and were required to be filed by the same deadlines as that established in section IV of the CMAS NPRM for other comments to the CMAS NPRM. The Commission sent a copy of the CMAS NPRM, including the IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA).2 In addition, the CMAS NPRM and IRFA were published in the Federal Register.3 A. Need for, and Objectives of, the Order 2. Section 602(a) of the WARN Act requires the Commission to “complete a proceeding to adopt relevant technical standards, protocols, procedures, and other technical requirements based on the recommendations of [the Commercial Mobile Service Alert Advisory Committee (CMSAAC)] necessary to enable commercial mobile service alerting capability for commercial mobile service providers that voluntarily elect to transmit emergency alerts.”4 Although the CMAS NPRM solicited comment on issues related to section 602(b) (CMS provider election to the CMAS) or 602(c) (Public Television Station equipment requirements), this CMAS First Report and Order only addresses issues raised by section 602(a) of the WARN Act.5 Accordingly, this FRFA only addressees the manner in which any commenters to the IRFA addressed the Commission’s adoption of technical standards, requirements and protocols for the CMAS as required by section 602(a) of the WARN Act. 3. This CMAS First Report and Order adopts rules necessary to enable CMS alerting capability for CMS providers who elect to transmit emergency alerts to their subscribers. The Order adopts technologically neutral rules governing the CMS provider-related functions and responsibilities with respect to the CMAS. Specifically, the rules address the CMS providers’ functions within the CMAS, including CMS provider-controlled elements within the CMAS architecture, emergency alert formatting, classes and elements, geographic targeting (geo- targeting) and accessibility for people with disabilities and the elderly. 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 5 U.S.C. § 603(a). 3 73 FR 546-01 (January 3, 2008). 4 WARN Act § 602(a). 5 As the CMAS First Report and Order indicates in note 16, supra, the Commission will address these other provisions of the WARN Act and related issues in subsequent Orders within the deadlines established by the statute. Federal Communications Commission FCC 08-99 45 B. Summary of Significant Issues Raised by Public Comments in Response to the IRFA 4. There were no comments filed that specifically addressed the IRFA. The only commenter that explicitly identified itself as a small business was Interstate Wireless, Inc., which supported the Commission’s adoption of the CMSAAC’s recommendations.6 Although Interstate Wireless did not comment specifically on the IRFA, it did state that the cost of building and maintaining a CMS Provider Gateway would be more than it and other similarly situated Small Business CMS providers could afford and still be able to provide the alert service to the public without cost. Accordingly, Interstate Wireless requested that the Federal Government either provide the proper software and reception equipment for the CMS Provider Gateways, or provide grants to the Small Business CMS providers to purchase, install, and maintain the equipment themselves. In paragraph 19, note 58 of the CMAS First Report and Order the Commission notes that questions of funding are not addressed by section 602(a) of the WARN Act and are this outside of the scope of this order.7 C. Description and Estimate of the Number of Small Entities to Which Rules Will 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.8 The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.”9 In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act.10 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).11 6. Wireless Telecommunications Carriers (except Satellite). Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category.12 Prior to that time, the SBA had developed a small business size standard for wireless firms within the now- superseded census categories of “Paging” and “Cellular and Other Wireless Telecommunications.”13 Under the present and prior categories, the SBA has deemed a wireless 6 Interstate Wireless Comments at 1. 7 See CMAS First Report and Order, n.58, infra 8 5 U.S.C. § 603(b). 9 5 U.S.C. § 601(6). 10 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). 11 15 U.S.C. § 632. 12 13 C.F.R. § 121.201, NAICS code 517210. 13 13 C.F.R. § 121.201, NAICS codes 517211, 517212. Federal Communications Commission FCC 08-99 46 business to be small if it has 1,500 or fewer employees. Because Census Bureau data are not yet available for the new category, we will estimate small business prevalence using the prior categories and associated data. For the first category of Paging, data for 2002 show that there were 807 firms that operated for the entire year.14 Of this total, 804 firms had employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more.15 For the second category of Cellular and Other Wireless Telecommunications, data for 2002 show that there were 1,397 firms that operated for the entire year.16 Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 1,000 employees or more.17 Thus, using the prior categories and the available data, we estimate that the majority of wireless firms can be considered small. 7. Cellular Service. As noted, the SBA has developed a small business size standard for small businesses in the category “Wireless Telecommunications Carriers (except satellite).”18 Under that SBA category, a business is small if it has 1,500 or fewer employees.19 Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category.20 Prior to that time, the SBA had developed a small business size standard for wireless firms within the now-superseded census categories of “Paging” and “Cellular and Other Wireless Telecommunications.”21 Accordingly, the pertinent data for this category is contained within the prior Wireless Telecommunications Carriers (except Satellite) category. 8. Auctions. Initially, we note that, as a general matter, the number of winning bidders that qualify as small businesses at the close of an auction does not necessarily represent the number of small businesses currently in service. Also, the Commission does not generally track subsequent business size unless, in the context of assignments or transfers, unjust enrichment issues are implicated. 9. Broadband Personal Communications Service. The broadband Personal Communications Service (PCS) spectrum is divided into six frequency blocks designated A through F, and the Commission has held auctions for each block. The Commission has created a small business size standard for Blocks C and F as an entity that has average gross revenues of less than $40 million in the three previous calendar years.22 For Block F, an additional small 14 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size (Including Legal Form of Organization,” Table 5, NAICS code 517211 (issued Nov. 2005). 15 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.” 16 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size (Including Legal Form of Organization,” Table 5, NAICS code 517212 (issued Nov. 2005). 17 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.” 18 13 C.F.R. § 121.201, North American Industry Classification System (NAICS) code 517210. 19 Id. 20 13 C.F.R. § 121.201, NAICS code 517210. 21 13 C.F.R. § 121.201, NAICS codes 517211, 517212. 22 See Amendment of Parts 20 and 24 of the Commission’s Rules – Broadband PCS Competitive Bidding and the Commercial Mobile Radio Service Spectrum Cap, Report and Order, 11 FCC Rcd 7824, 7850-7852 ¶¶ 57-60 (1996); see also 47 C.F.R. § 24.720(b). Federal Communications Commission FCC 08-99 47 business size standard for “very small business” was added and is defined as an entity that, together with its affiliates, has average gross revenues of not more than $15 million for the preceding three calendar years.23 These small business size standards, in the context of broadband PCS auctions, have been approved by the SBA.24 No small businesses within the SBA-approved small business size standards bid successfully for licenses in Blocks A and B. There were 90 winning bidders that qualified as small entities in the C Block auctions. A total of 93 “small” and “very small” business bidders won approximately 40 percent of the 1,479 licenses for Blocks D, E, and F.25 On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block licenses; there were 113 small business winning bidders.26 On January 26, 2001, the Commission completed the auction of 422 C and F PCS licenses in Auction 35.27 Of the 35 winning bidders in this auction, 29 qualified as “small” or “very small” businesses. Subsequent events concerning Auction 35, including judicial and agency determinations, resulted in a total of 163 C and F Block licenses being available for grant. 10. Narrowband Personal Communications Service. The Commission held an auction for Narrowband Personal Communications Service (PCS) licenses that commenced on July 25, 1994, and closed on July 29, 1994. A second commenced on October 26, 1994 and closed on November 8, 1994. For purposes of the first two Narrowband PCS auctions, “small businesses” were entities with average gross revenues for the prior three calendar years of $40 million or less.28 Through these auctions, the Commission awarded a total of forty-one licenses, 11 of which were obtained by four small businesses.29 To ensure meaningful participation by small business entities in future auctions, the Commission adopted a two-tiered small business size standard in the Narrowband PCS Second Report and Order.30 A “small business” is an entity that, together with affiliates and controlling interests, has average gross revenues for the three preceding years of not more than $40 million.31 A “very small business” is an entity that, together with affiliates and controlling interests, has average gross revenues for the three 23 See Amendment of Parts 20 and 24 of the Commission’s Rules – Broadband PCS Competitive Bidding and the Commercial Mobile Radio Service Spectrum Cap, Report and Order, 11 FCC Rcd 7824, 7852 ¶ 60. 24 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, dated December 2, 1998. 25 FCC News, “Broadband PCS, D, E and F Block Auction Closes,” No. 71744 (rel. January 14, 1997). 26 See “C, D, E, and F Block Broadband PCS Auction Closes,” Public Notice, 14 FCC Rcd 6688 (WTB 1999). 27 See “C and F Block Broadband PCS Auction Closes; Winning Bidders Announced,” Public Notice, 16 FCC Rcd 2339 (2001). 28 Implementation of section 309(j) of the Communications Act – Competitive Bidding Narrowband PCS, Third Memorandum Opinion and Order and Further Notice of Proposed Rulemaking, 10 FCC Rcd 175, 196 ¶ 46 (1994). 29 See “Announcing the High Bidders in the Auction of ten Nationwide Narrowband PCS Licenses, Winning Bids Total $617,006,674,” Public Notice, PNWL 94-004 (rel. Aug. 2, 1994); “Announcing the High Bidders in the Auction of 30 Regional Narrowband PCS Licenses; Winning Bids Total $490,901,787,” Public Notice, PNWL 94- 27 (rel. Nov. 9, 1994). 30 Amendment of the Commission’s Rules to Establish New Personal Communications Services, Narrowband PCS, Second Report and Order and Second Further Notice of Proposed Rule Making, 15 FCC Rcd 10456, 10476 ¶ 40 (2000). 31 Id. Federal Communications Commission FCC 08-99 48 preceding years of not more than $15 million.32 The SBA has approved these small business size standards.33 A third auction commenced on October 3, 2001 and closed on October 16, 2001. Here, five bidders won 317 (MTA and nationwide) licenses.34 Three of these claimed status as a small or very small entity and won 311 licenses. 11. Wireless Communications Services. This service can be used for fixed, mobile, radiolocation, and digital audio broadcasting satellite uses in the 2305-2320 MHz and 2345-2360 MHz bands. The Commission defined “small business” for the wireless communications services (WCS) auction as an entity with average gross revenues of $40 million for each of the three preceding years, and a “very small business” as an entity with average gross revenues of $15 million for each of the three preceding years.35 The SBA has approved these definitions.36 The Commission auctioned geographic area licenses in the WCS service. In the auction, which commenced on April 15, 1997 and closed on April 25, 1997, there were seven bidders that won 31 licenses that qualified as very small business entities, and one bidder that won one license that qualified as a small business entity. 12. 700 MHz Guard Bands Licenses. In the 700 MHz Guard Bands Order, the Commission adopted size standards for “small businesses” and “very small businesses” for purposes of determining their eligibility for special provisions such as bidding credits and installment payments.37 A small business in this service is an entity that, together with its affiliates and controlling principals, has average gross revenues not exceeding $40 million for the preceding three years.38 Additionally, a “very small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $15 million for the preceding three years.39 SBA approval of these definitions is not required.40 An auction of 52 Major Economic Area (MEA) licenses for each of two spectrum blocks commenced on September 6, 2000, and closed on September 21, 2000.41 Of the 104 licenses 32 Id. 33 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, dated December 2, 1998. 34 See “Narrowband PCS Auction Closes,” Public Notice, 16 FCC Rcd 18663 (WTB 2001). 35 Amendment of the Commission’s Rules to Establish Part 27, the Wireless Communications Service (WCS), Report and Order, 12 FCC Rcd 10785, 10879 ¶ 194 (1997). 36 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, dated December 2, 1998. 37 See Service Rules for the 746-764 MHz Bands, and Revisions to Part 27 of the Commission’s Rules, Second Report and Order, 15 FCC Rcd 5299 (2000). 38 Id. at 5343 ¶ 108. 39 Id. 40 Id. At 5343 ¶ 108 n.246 (for the 746-764 MHz and 776-704 MHz bands, the Commission is exempt from 15 U.S.C. § 632, which requires Federal agencies to obtain Small Business Administration approval before adopting small business size standards). 41 See “700 MHz Guard Bands Auction Closes: Winning Bidders Announced,” Public Notice, 15 FCC Rcd 18026 (2000). Federal Communications Commission FCC 08-99 49 auctioned, 96 licenses were sold to nine bidders. Five of these bidders were small businesses that won a total of 26 licenses. A second auction of remaining 700 MHz Guard Bands licenses commenced on February 13, 2001, and closed on February 21, 2001. All eight of the licenses auctioned were sold to three bidders. One of these bidders was a small business that won a total of two licenses.42 Subsequently, in the 700 MHz Second Report and Order, the Commission reorganized the licenses pursuant to an agreement among most of the licensees, resulting in a spectral relocation of the first set of paired spectrum block licenses, and an elimination of the second set of paired spectrum block licenses (many of which were already vacant, reclaimed by the Commission from Nextel).43 A single licensee that did not participate in the agreement was grandfathered in the initial spectral location for its two licenses in the second set of paired spectrum blocks.44 Accordingly, at this time there are 54 licenses in the 700 MHz Guard Bands. 13. 700 MHz Band Commercial Licenses. There is 80 megahertz of non-Guard Band spectrum in the 700 MHz Band that is designated for commercial use: 698-757, 758-763, 776- 787, and 788-793 MHz Bands. With one exception, the Commission adopted criteria for defining two groups of small businesses for purposes of determining their eligibility for bidding credits at auction. These two categories are: (1) “small business,” which is defined as an entity that has attributed average annual gross revenues that do not exceed $15 million during the preceding three years; and (2) “very small business,” which is defined as an entity with attributed average annual gross revenues that do not exceed $40 million for the preceding three years.45 In Block C of the Lower 700 MHz Band (710-716 MHz and 740-746 MHz), which was licensed on the basis of 734 Cellular Market Areas, the Commission adopted a third criterion for determining eligibility for bidding credits: an “entrepreneur,” which is defined as an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $3 million for the preceding three years.46 The SBA has approved these small size standards.47 14. An auction of 740 licenses for Blocks C (710-716 MHz and 740-746 MHz) and D (716-722 MHz) of the Lower 700 MHz Band commenced on August 27, 2002, and closed on September 18, 2002. Of the 740 licenses available for auction, 484 licenses were sold to 102 winning bidders. Seventy-two of the winning bidders claimed small business, very small business, or entrepreneur status and won a total of 329 licenses.48 A second auction commenced on May 28, 2003, and closed on June 13, 2003, and included 256 licenses: five EAG licenses 42 See “700 MHz Guard Bands Auctions Closes: Winning Bidders Announced,” Public Notice, 16 FCC Rcd 4590 (WTB 2001). 43 See In the Matter of Service Rules for the 698-746, 747-762 and 777-792 MHz Bands, WT Docket 06-150, Second Report and Order, 22 FCC Rcd 15289, 15339-15344 ¶¶ 118-134 (2007) (700 MHz Second Report and Order). 44 Id. 45 See Auction of 700 MHz Band Licenses Scheduled for January 24, 2008, AU Docket No. 07-157, Notice and Filing Requirements, Minimum Opening Bids, Reserve Prices, Upfront Payments, and Other Procedures for Auctions 73 and 76, DA 07-4171 at ¶ 70 (WTB rel. Oct. 5, 2007); Reallocation and Service Rules for the 698-746 MHz Spectrum Band (Television Channels 52-59), Report and Order, 17 FCC Rcd 1022, 1087-88 (2002). 46 Id. at 1088. 47 See Letter to Thomas Sugrue, Chief, Wireless Telecommunications Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, dated August 10, 1999. 48 See “Lower 700 MHz Band Auction Closes,” Public Notice, 17 FCC Rcd 17272 (WTB 2002). Federal Communications Commission FCC 08-99 50 and 251 CMA licenses.49 Seventeen winning bidders claimed small or very small business status and won 60 licenses, and nine winning bidders claimed entrepreneur status and won 154 licenses.50 15. The remaining 62 megahertz of commercial spectrum is currently scheduled for auction on January 24, 2008. As explained above, bidding credits for all of these licenses will be available to “small businesses” and “very small businesses.” 16. Advanced Wireless Services. In the AWS-1 Report and Order, the Commission adopted rules that affect applicants who wish to provide service in the 1710-1755 MHz and 2110-2155 MHz bands.51 The Commission did not know precisely the type of service that a licensee in these bands might seek to provide. Nonetheless, the Commission anticipated that the services that will be deployed in these bands may have capital requirements comparable to those in the broadband Personal Communications Service (PCS), and that the licensees in these bands will be presented with issues and costs similar to those presented to broadband PCS licensees. Further, at the time the broadband PCS service was established, it was similarly anticipated that it would facilitate the introduction of a new generation of service. Therefore, the AWS-1 Report and Order adopts the same small business size definition that the Commission adopted for the broadband PCS service and that the SBA approved.52 In particular, the AWS-1 Report and Order defines a “small business” as an entity with average annual gross revenues for the preceding three years not exceeding $40 million, and a “very small business” as an entity with average annual gross revenues for the preceding three years not exceeding $15 million. The AWS-1 Report and Order also provides small businesses with a bidding credit of 15 percent and very small businesses with a bidding credit of 25 percent. 17. Common Carrier Paging. As noted, the SBA has developed a small business size standard for wireless firms within the broad economic census category of "Wireless Telecommunications Carriers (except Satellite)."53 Under this category, the SBA deems a business to be small if it has 1,500 or fewer employees. Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category.54 Prior to that time, the SBA had developed a small business size standard for wireless firms within the now-superseded census categories of “Paging” and “Cellular and Other Wireless Telecommunications.”55 Under the present and prior categories, the SBA has deemed a wireless business to be small if it has 1,500 or fewer employees. Because Census Bureau data are not yet available for the new category, we will estimate small business prevalence using the prior categories and associated 49 See “Lower 700 MHz Band Auction Closes,” Public Notice, 18 FCC Rcd 11873 (WTB 2003). 50 Id. 51 Service Rules for Advanced Wireless Services in the 1.7 GHz and 2.1 GHz Bands, WT Docket No. 02-353, Report and Order, 18 FCC Rcd 25162 (2003) (AWS-1 Report and Order). 52 See Implementation of section 309(j) of the Communications Act -- Competitive Bidding, Third Memorandum Opinion and Order and Further Notice of Proposed Rulemaking, 10 FCC Rcd 175, 196 (1995); Implementation of section 309(j) of the Communications Act -- Competitive Bidding, Fifth Report and Order, 9 FCC Rcd 5581-5584 (1995); 47 C.F.R. §§ 24.320(b) and 24.720(b). 53 13 C.F.R. § 121.201, NAICS code 517211. 54 13 C.F.R. § 121.201, NAICS code 517210. 55 13 C.F.R. § 121.201, NAICS codes 517211, 517210. Federal Communications Commission FCC 08-99 51 data. For the first category of Paging, data for 2002 show that there were 807 firms that operated for the entire year.56 Of this total, 804 firms had employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more.57 For the second category of Cellular and Other Wireless Telecommunications, data for 2002 show that there were 1,397 firms that operated for the entire year.58 Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 1,000 employees or more.59 Thus, using the prior categories and the available data, we estimate that the majority of wireless firms can be considered small. Thus, under this category, the majority of firms can be considered small. 18. In the Paging Third Report and Order, we developed a small business size standard for “small businesses” and “very small businesses” for purposes of determining their eligibility for special provisions such as bidding credits and installment payments.60 A “small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues not exceeding $15 million for the preceding three years. Additionally, a “very small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $3 million for the preceding three years.61 The SBA has approved these small business size standards.62 An auction of Metropolitan Economic Area licenses commenced on February 24, 2000, and closed on March 2, 2000.63 Of the 985 licenses auctioned, 440 were sold. Fifty-seven companies claiming small business status won. Also, according to Commission data, 365 carriers reported that they were engaged in the provision of paging and messaging services.64 Of those, we estimate that 360 are small, under the SBA-approved small business size standard.65 19. Wireless Communications Service. This service can be used for fixed, mobile, radiolocation, and digital audio broadcasting satellite uses. The Commission established small 56 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size (Including Legal Form of Organization,” Table 5, NAICS code 517211 (issued Nov. 2005). 57 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.” 58 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size (Including Legal Form of Organization,” Table 5, NAICS code 517212 (issued Nov. 2005). 59 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.” 60 Amendment of Part 90 of the Commission’s Rules to Provide for the Use of the 220-222 MHz Band by the Private Land Mobile Radio Service, PR Docket No. 89-552, Third Report and Order and Fifth Notice of Proposed Rulemaking, 12 FCC Rcd 10943, 11068-70, ¶¶s. 291-295, 62 FR 16004 (Apr. 3, 1997). 61 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications Bureau, FCC, from A. Alvarez, Administrator, SBA (Dec. 2, 1998). 62 Revision of Part 22 and Part 90 of the Commission’s Rules to Facilitate Future Development of Paging Systems, Memorandum Opinion and Order on Reconsideration and Third Report and Order, 14 FCC Rcd 10030, ¶¶s. 98-107 (1999). 63 Id. at 10085, ¶. 98. 64 FCC Wireline Competition Bureau, Industry Analysis and Technology Division, “Trends in Telephone Service” at Table 5.3., page 5-5 (Feb. 2007). This source uses data that are current as of October 20, 2005. 65 Id. Federal Communications Commission FCC 08-99 52 business size standards for the wireless communications services (WCS) auction.66 A “small business” is an entity with average gross revenues of $40 million for each of the three preceding years, and a “very small business” is an entity with average gross revenues of $15 million for each of the three preceding years. The SBA has approved these small business size standards.67 The Commission auctioned geographic area licenses in the WCS service. In the auction, there were seven winning bidders that qualified as “very small business” entities, and one that qualified as a “small business” entity. 20. Wireless Communications Equipment Manufacturers. While these entities are merely indirectly affected by our action, we are describing them to achieve a fuller record. The Census Bureau defines this category as follows: “This industry comprises establishments primarily engaged in manufacturing radio and television broadcast and wireless communications equipment. Examples of products made by these establishments are: transmitting and receiving antennas, cable television equipment, GPS equipment, pagers, cellular phones, mobile communications equipment, and radio and television studio and broadcasting equipment.” The SBA has developed a small business size standard for Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing, which is: all such firms having 750 or fewer employees.68 According to Census Bureau data for 2002, there were a total of 1,041 establishments in this category that operated for the entire year. Of this total, 1,010 had employment of under 500, and an additional 13 had employment of 500 to 999. Thus, under this size standard, the majority of firms can be considered small.69 21. Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing. The Census Bureau defines this category as follows: “This industry comprises establishments primarily engaged in manufacturing radio and television broadcast and wireless communications equipment. Examples of products made by these establishments are: transmitting and receiving antennas, cable television equipment, GPS equipment, pagers, cellular phones, mobile communications equipment, and radio and television studio and broadcasting equipment.”70 The SBA has developed a small business size standard for Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing, which is: all such firms having 750 or fewer employees.71 According to Census Bureau data for 2002, there were a total of 1,041 establishments in this category that operated for the entire year.72 Of this total, 1,010 66 Public Notice, “Auction of Wireless Communications Services, Auction Notes and Filing Requirements for 128 WCS Licenses Scheduled for April 15, 1997,” DA 97-386, Feb. 21, 1997. 67 SBA Dec. 2, 1998 Letter. 68 NAICS code 334220. 69 NAICS code 11210. 70 U.S. Census Bureau, 2002 NAICS Definitions, “334220 Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing”; http://www.census.gov/epcd/naics02/def/NDEF334.HTM#N3342. 71 13 C.F.R. § 121.201, NAICS code 334220. 72 U.S. Census Bureau, American FactFinder, 2002 Economic Census, Industry Series, Industry Statistics by Employment Size, NAICS code 334220 (released May 26, 2005); http://factfinder.census.gov. The number of “establishments” is a less helpful indicator of small business prevalence in this context than would be the number of “firms” or “companies,” because the latter take into account the concept of common ownership or control. Any single physical location for an entity is an establishment, even though that location may be owned by a different establishment. Thus, the numbers given may reflect inflated numbers of businesses in this category, including the (continued....) Federal Communications Commission FCC 08-99 53 had employment of under 500, and an additional 13 had employment of 500 to 999.73 Thus, under this size standard, the majority of firms can be considered small. 22. Software Publishers. While these entities are merely indirectly affected by our action, we are describing them to achieve a fuller record. These companies may design, develop or publish software and may provide other support services to software purchasers, such as providing documentation or assisting in installation. The companies may also design software to meet the needs of specific users. The SBA has developed a small business size standard of $23 million or less in average annual receipts for the category of Software Publishers. For Software Publishers, Census Bureau data for 2002 indicate that there were 6,155 firms in the category that operated for the entire year. Of these, 7,633 had annual receipts of under $10 million, and an additional 403 firms had receipts of between $10 million and $24, 999,999. For providers of Custom Computer Programming Services, the Census Bureau data indicate that there were 32,269 firms that operated for the entire year. Of these, 31,416 had annual receipts of under $10 million, and an additional 565 firms had receipts of between $10 million and $24,999,999. Consequently, we estimate that the majority of the firms in this category are small entities that may be affected by our action. 23. NCE and Public Broadcast Stations. The Census Bureau defines this category as follows: “This industry comprises establishments primarily engaged in broadcasting images together with sound. These establishments operate television broadcasting studios and facilities for the programming and transmission of programs to the public.”74 The SBA has created a small business size standard for Television Broadcasting entities, which is: such firms having $13 million or less in annual receipts.75 According to Commission staff review of the BIA Publications, Inc., Master Access Television Analyzer Database as of May 16, 2003, about 814 of the 1,220 commercial television stations in the United States had revenues of $12 (twelve) million or less. We note, however, that in assessing whether a business concern qualifies as small under the above definition, business (control) affiliations76 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. 24. 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 (...continued from previous page) numbers of small businesses. In this category, the Census breaks-out data for firms or companies only to give the total number of such entities for 2002, which was 929. 73 Id. An additional 18 establishments had employment of 1,000 or more. 74 U.S. Census Bureau, 2002 NAICS Definitions, “515120 Television Broadcasting” (partial definition); http://www.census.gov/epcd/naics02/def/NDEF515.HTM. 75 13 C.F.R. § 121.201, NAICS code 515120. 76 “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. § 21.103(a)(1). Federal Communications Commission FCC 08-99 54 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. There are also 2,117 low power television stations (LPTV).77 Given the nature of this service, we will presume that all LPTV licensees qualify as small entities under the above SBA small business size standard. 25. The Commission has, under SBA regulations, estimated the number of licensed NCE television stations to be 380.78 We note, however, that, in assessing whether a business concern qualifies as small under the above definition, business (control) affiliations79 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. A. Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements 26. This Report and Order may contain new information collection requirements subject to the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. If the Commission determines that the Report and Order contains collection subject to the PRA, it will be submitted to the Office of Management and Budget (OMB) for review under section 3507(d) of the PRA at an appropriate time. At that time, OMB, the general public, and other Federal agencies will be 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. B. Steps Taken to Minimize the Significant Economic Impact on Small Entities, and Significant Alternatives Considered 27. 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.”80 28. As noted in paragraph 2 above, this CMAS First Report and Order deals only with the WARN Act section 602(a) requirement that the Commission adopt technical standards, 77 FCC News Release, “Broadcast Station Totals as of September 30, 2005.” 78 See Broadcast Station Totals, supra IRFA, n. 11. 79 “[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). 80 5 U.S.C. § 603(c)(1) – (c)(4). Federal Communications Commission FCC 08-99 55 protocols, procedures, and other technical requirements based on the recommendations of the Commercial Mobile Service Alert Advisory Committee. The entities affected by this order were largely the members of the CMSAAC. In its formation of the CMSAAC, the Commission made sure to include representatives of small businesses among the advisory committee members. Also, as we indicate by our treatment of the comments of Interstate Wireless in paragraph 15 above, the technical requirements, standards and protocols on which the Commission sought comment already contain concerns raised by small businesses.81 The WARN ACT NPRM also sought comment on a number of alternatives to the recommendations of the CMSAAC, such as the Digital EAS82 and FM sub-carrier based alerts.83 In its consideration of these and other alternatives the CMSAAC recommendations, the Commission has attempted to impose minimal regulation on small entities to the extent consistent with our goal of advancing our public safety mission by adopting technical requirements, standards and protocols for a CMAS that CMS providers would elect to provide alerts and warnings to their customers. The affected CMS providers have overwhelmingly expressed their willingness to cooperate in the formation of the CMAS, and we anticipate that the standards, protocols and requirement that we adopt in this order will encourage CMS providers to work with other industry and government entities to complete and participate in the CMAS. C. Federal Rules that May Duplicate, Overlap, or Conflict with the Proposed Rules 29. None. 81 See infra, n.53. 82 See infra ¶ 12. 83 See infra ¶ 33. Federal Communications Commission FCC 08-99 56 APPENDIX C Final Rules PART 10—COMMERCIAL MOBILE ALERT SYSTEM Subpart A—General Information Sec. 10.1 Basis. 10.2 Purpose. . 10.10 Definitions. 10.11 CMAS Implementation Timeline. Subpart B—Election to Participate in Commercial Mobile Alert System Reserved. Subpart C—System Architecture Sec. 10.300 Alert Aggregator (reserved). 10.310 Federal Alert Gateway (reserved). 10.320 Provider Gateway Requirements. 10.330 Provider Infrastructure Requirements. Subpart D—Alert Message Requirements Sec. 10.400 Classification. 10.410 Prioritization. 10.420 Message Elements. 10.430 Character Limit. 10.440 Embedded Reference Prohibition. 10.450 Geographic Targeting. 10.460 Retransmission Frequency (reserved). 10.470 Roaming. Subpart E—Equipment Requirements Sec. 10.500 General Requirements. 10.510 Call Preemption Prohibition. 10.520 Common Audio Attention Signal. 10.530 Common Vibration Cadence. 10.540 Attestation Requirement. (reserved). Federal Communications Commission FCC 08-99 57 Subpart A—General Information § 10.1 Basis. The rules in this part are issued pursuant to the authority contained in the Warning, Alert, and Response Network Act, Title VI of the Security and Accountability for Every Port Act of 2006, Pub. L. 109-347, Titles I through III of the Communications Act of 1934, as amended, and Executive Order 13407 of June 26, 2006, Public Alert and Warning System, 71 Federal Register 36975 (2006). § 10.2 Purpose. The rules in this part establish the requirements for participation in the voluntary Commercial Mobile Alert System. § 10.10 Definitions. (a) Alert Message. An Alert Message is a message that is intended to provide the recipient information regarding an emergency, and that meets the requirements for transmission by a Participating Commercial Mobile Service Provider under this part. (b) Common Alerting Protocol. The Common Alerting Protocol (CAP) refers to Organization for the Advancement of Structured Information Standards (OASIS) Standard CAP-V1.1, October 2005 (available at http://www.oasis-open.org/specs/index.php#capv1.1), or any subsequent version of CAP adopted by OASIS and implemented by the CMAS. (c) Commercial Mobile Alert System. The Commercial Mobile Alert System (CMAS) refers to the voluntary emergency alerting system established by this part, whereby Commercial Mobile Service Providers may elect to transmit Alert Messages to the public. (d) Commercial Mobile Service Provider. A Commercial Mobile Service Provider (or CMS Provider) is an FCC licensee providing commercial mobile service as defined in section 332 (d)(1) of the Communications Act of 1934 (47 U.S.C. 332(d)(1)). Section 332(d)(1) defines the term commercial mobile service as any mobile service (as defined in 47 U.S.C. 153) that is provided for profit and makes interconnected service available (a) to the public or (b) to such classes of eligible users as to be effectively available to a substantial portion of the public, as specified by regulation by the Commission. (g) County and County Equivalent. The terms County and County Equivalent as used in this part are defined by Federal Information Processing Standards (FIPS) 6-4, which provides the names and codes that represent the counties and other entities treated as equivalent legal and/or statistical subdivisions of the 50 States, the District of Columbia, and the possessions and freely associated areas of the United States. Counties are considered to be the “first-order subdivisions” of each State and statistically equivalent entity, regardless of their local designations (county, parish, borough, etc.). Thus, the following entities are considered to be equivalent to counties for legal and/or statistical purposes: The parishes of Louisiana; the boroughs and census areas of Alaska; the District of Columbia; the independent cities of Maryland, Missouri, Nevada, and Virginia; that part of Yellowstone National Park in Montana; Federal Communications Commission FCC 08-99 58 and various entities in the possessions and associated areas. The FIPS codes and FIPS code documentation are available online at http://www.itl.nist.gov/fipspubs/index.htm. (f) Participating Commercial Mobile Service Provider. A Participating Commercial Mobile Service Provider (or a Participating CMS Provider) is a Commercial Mobile Service Provider that has voluntarily elected to transmit Alert Messages under subpart B of this part. § 10.11 CMAS Implementation Timeline. Notwithstanding anything in this part to the contrary, a Participating CMS provider shall comply with the rules in this part no later than 10 months from the date of announcement by the FCC of an entity or entities to provide the Alert Aggregator and Federal alert gateway functions. Subpart B—Election to Participate in Commercial Mobile Alert System Reserved. Subpart C—System Architecture § 10.300 Alert Aggregator. Reserved. § 10.310 Federal Alert Gateway. Reserved. § 10.320 Provider Alert Gateway Requirements. This section specifies the functions that each Participating Commercial Mobile Service provider is required to support and perform at its CMS provider gateways. (a) General. The CMS provider gateway must provide secure, redundant, and reliable connections to receive Alert Messages from the Federal alert gateway. Each CMS provider gateway must be identified by a unique IP address or domain name. (b) Authentication and Validation. The CMS provider gateway must authenticate interactions with the Federal alert gateway, and validate Alert Message integrity and parameters. The CMS provider gateway must provide an error message immediately to the Federal alert gateway if a validation fails. (c) Security. The CMS provider gateway must support standardized IP-based security mechanisms such as a firewall, and support the defined CMAS “C” interface and associated protocols between the Federal alert gateway and the CMS provider gateway. (d) Geographic Targeting. The CMS provider gateway must determine whether the provider has elected to transmit an Alert Message within a specified alert area and, if so, map the Alert Message to an associated set of transmission sites. (e) Message Management. (1) Formatting. The CMS provider gateway is not required to perform any formatting, reformatting, or translation of an Alert Message, except for transcoding a text, audio, video, or multimedia file into the format supported by mobile devices. Federal Communications Commission FCC 08-99 59 (2) Reception. The CMS provider gateway must support a mechanism to stop and start Alert Message deliveries from the Federal alert gateway to the CMS provider gateway. (3) Prioritization. The CMS provider gateway must process an Alert Message on a first in–first out basis except for Presidential Alerts, which must be processed before all non-Presidential alerts. (4) Distribution. A Participating CMS provider must deploy one or more CMS provider gateways to support distribution of Alert Messages and to manage Alert Message traffic. (5) Retransmission. The CMS provider gateway must manage and execute Alert Message retransmission, and support a mechanism to manage congestion within the CMS provider’s infrastructure. (f) CMS Provider Profile. The CMS provider gateway will provide profile information on the CMS provider for the Federal alert gateway to maintain at the Federal alert gateway. This profile information must be provided by an authorized CMS provider representative to the Federal alert gateway administrator. The profile information must include the data listed in Table 10.320(f) and must comply with the following procedures: (1) The information must be provided 30 days in advance of the date when the CMS provider begins to transmit CMAS alerts. (2) Updates of any CMS provider profiles must be provided in writing at least 30 days in advance of the effective change date. Federal Communications Commission FCC 08-99 60 Table 10.320(f) CMSP Profile on Federal Alert Gateway Profile Parameter Parameter Election Description CMSP Name Unique identification of CMSP CMSP gateway Address IP address or Domain Name Alternate IP address Optional and subject to implementation Geo-Location Filtering If “yes” the only CMAM issued in the listed states will be sent to the CMSP gateway. If “no”, all CMAM will be sent to the CMSP gateway. If yes, list of states CMAC Geocode for state List can be state name or abbreviated state name. § 10.330 Provider Infrastructure Requirements. This section specifies the general functions that a Participating CMS Provider is required to perform within their infrastructure. Infrastructure functions are dependent upon the capabilities of the delivery technologies implemented by a Participating CMS Provider. (a) Distribution of Alert Messages to mobile devices. (b) Authentication of interactions with mobile devices. (c) Reference Points D & E. Reference Point D is the interface between a CMS Provider gateway and its infrastructure. Reference Point E is the interface between a provider’s infrastructure and mobile devices including air interfaces. Reference Points D and E protocols are defined and controlled by each Participating CMS Provider. Subpart D—Alert Message Requirements § 10.400 Classification. A Participating CMS Provider is required to receive and transmit three classes of Alert Messages: Presidential Alert; Imminent Threat Alert; and Child Abduction Emergency/AMBER Alert. (a) Presidential Alert. A Presidential Alert is an alert issued by the President of the United States or the President’s authorized designee. (b) Imminent Threat Alert. An Imminent Threat Alert is an alert that meets a minimum value for each of three CAP elements: Urgency, Severity, and Certainty. Federal Communications Commission FCC 08-99 61 (1) Urgency. The CAP Urgency element must be either Immediate (i.e., responsive action should be taken immediately) or Expected (i.e., responsive action should be taken soon, within the next hour). (2) Severity. The CAP Severity element must be either Extreme (i.e., an extraordinary threat to life or property) or Severe (i.e., a significant threat to life or property). (3) Certainty. The CAP Certainty element must be either Observed (i.e., determined to have occurred or to be ongoing) or Likely (i.e., has a probability of greater than 50 percent). (c) Child Abduction Emergency/AMBER Alert. An AMBER Alert is an alert initiated by a local government official based on the U.S. Department of Justice’s five criteria that should be met before an alert is activated: (1) law enforcement confirms a child has been abducted; (2) the child is 17 years or younger; (3) law enforcement believes the child is in imminent danger of serious bodily harm or death; (4) there is enough descriptive information about the victim and the abduction to believe an immediate broadcast alert will help; and (5) the child’s name and other data have been entered into the National Crime Information Center. There are four types of AMBER Alerts: Family Abduction; Non-family Abduction; Lost, Injured or Otherwise Missing; and Endangered Runaway. (1) Family Abduction. A Family Abduction (FA) alert involves an abductor who is a family member of the abducted child such as a parent, aunt, grandfather, or stepfather. (2) Nonfamily Abduction. A Nonfamily Abduction (NFA) alert involves an abductor unrelated to the abducted child, either someone unknown to the child and/or the child’s family or an acquaintance/friend of the child and/or the child’s family. (3) Lost, Injured, or Otherwise Missing. A Lost, Injured, or Otherwise Missing (LIM) alert involves a case where the circumstances of the child’s disappearance are unknown. (4) Endangered Runaway. An Endangered Runaway (ERU) alert involves a missing child who is believed to have run away and in imminent danger. § 10.410 Prioritization. A Participating CMS Provider is required to transmit Presidential Alerts upon receipt. Presidential Alerts preempt all other Alert Messages. A Participating CMS Provider is required to transmit Imminent Threat Alerts and AMBER Alerts on a first in–first out (FIFO) basis. § 10.420 Message Elements. A CMAS Alert Message processed by a Participating CMS Provider shall include five mandatory CAP elements—Event Type; Area Affected; Recommended Action; Expiration Time (with time zone); and Sending Agency. This requirement does not apply to Presidential Alerts. § 10.430 Character Limit. A CMAS Alert Message processed by a Participating CMS Provider must not exceed 90 characters of alphanumeric text. § 10.440 Embedded Reference Prohibition. A CMAS Alert Message processed by a Participating CMS Provider must not include an embedded Uniform Resource Locator (URL), which is a reference (an address) to a resource on Federal Communications Commission FCC 08-99 62 the Internet, or an embedded telephone number. This prohibition does not apply to Presidential Alerts. § 10.450 Geographic Targeting. This section establishes minimum requirements for the geographic targeting of Alert Messages. A Participating CMS Provider will determine which of its network facilities, elements, and locations will be used to geographically target Alert Messages. A Participating CMS Provider must transmit any Alert Message that is specified by a geocode, circle, or polygon to an area not larger than the provider’s approximation of coverage for the Counties or County Equivalents with which that geocode, circle, or polygon intersects. If, however, the propagation area of a provider’s transmission site exceeds a single County or County Equivalent, a Participating CMS Provider may transmit an Alert Message to an area not exceeding the propagation area. § 10.460 Retransmission Frequency. Reserved. § 10.470 Roaming. When, pursuant to a roaming agreement (see § 20.12 of the Commission's rules), a subscriber receives services from a roamed-upon network of a Participating CMS Provider, the Participating CMS Provider must support CMAS alerts to the roaming subscriber to the extent the subscriber’s mobile device is configured for and technically capable of receiving CMAS alerts.. Subpart E—Equipment Requirements § 10.500 General Requirements. CMAS mobile device functionality is dependent on the capabilities of a Participating CMS Provider’s delivery technologies. Mobile devices are required to perform the following functions: (a) Authentication of interactions with CMS Provider infrastructure. (b) Monitoring for Alert Messages. (c) Maintaining subscriber alert opt-out selections, if any. (d) Maintaining subscriber alert language preferences, if any. (e) Extraction of alert content in English or the subscriber’s preferred language, if applicable. (f) Presentation of alert content to the device, consistent with subscriber opt-out selections. Presidential Alerts must always be presented. (g) Detection and suppression of presentation of duplicate alerts. § 10.510 Call Preemption Prohibition. Devices marketed for public use under Part 10 must not enable an Alert Message to preempt an active voice or data session. Federal Communications Commission FCC 08-99 63 § 10.520 Common Audio Attention Signal. A Participating CMS Provider and equipment manufacturers may only market devices for public use under Part 10 that include an audio attention signal that meets the requirements of this section. (a) The audio attention signal must have a temporal pattern of one long tone of two (2) seconds, followed by two short tones of one (1) second each, with a half (0.5) second interval between each tone. The entire sequence must be repeated twice with a half (0.5) second interval between each repetition. (b) For devices that have polyphonic capabilities, the audio attention signal must consist of the fundamental frequencies of 853 Hz and 960 Hz transmitted simultaneously. (c) For devices with only a monophonic capability, the audio attention signal must be 960 Hz. (d) The audio attention signal must be restricted to use for Alert Messages under Part 10. (e) A device may include the capability to mute the audio attention signal. § 10.530 Common Vibration Cadence. A Participating CMS Provider and equipment manufacturers may only market devices for public use under Part 10 that include a vibration cadence capability that meets the requirements of this section. (a) The vibration cadence must have a temporal pattern of one long vibration of two (2) seconds, followed by two short vibrations of one (1) second each, with a half (0.5) second interval between each vibration. The entire sequence must be repeated twice with a half (0.5) second interval between each repetition. (b) The vibration cadence must be restricted to use for Alert Messages under Part 10. (c) A device may include the capability to mute the vibration cadence. § 10.540 Attestation Requirement. Reserved. Federal Communications Commission FCC 08-99 64 STATEMENT OF CHAIRMAN KEVIN J. MARTIN Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 With the American public increasingly relying on wireless communications in everyday life, it is essential that we support and advance new ways to share critical, time-sensitive information with them in times of crisis. The ability to deliver accurate and timely warnings and alerts through cell phones and other mobile devices is an important next step in our efforts to help ensure that the American public has the information they need to take action to protect themselves and their families prior to, and during, disasters and other emergencies. The Commercial Mobile Services Alert Advisory Committee’s recommendations were instrumental in moving this process forward. I commend them for their efforts No one questions the value that an effective Commercial Mobile Alert System will have on the safety and welfare of the American public. Accordingly, we welcomed the challenge offered to us by the WARN Act as an opportunity to meet our public safety obligations under the Communications Act and to achieve one of our top priorities - an effective alert system for wireless devices. By adopting technical requirements for the wireless alerting system today, we are enabling wireless providers that choose to participate in this system to begin designing their networks to deliver mobile alerts. It would have been better, of course, if we had a Federal entity in place now to take on the role of alert aggregator and gateway. We are hopeful that we have initiated the dialogue that will allow an appropriate Federal entity to assume that central role in an expeditious manner. This system has the potential to significantly impact the way Americans receive critical warnings on the go, whether they are at home, work, or vacationing. As we go forward, given the important public safety purpose that these alerts serve, I encourage wireless providers to participate fully in this valuable system. Federal Communications Commission FCC 08-99 65 STATEMENT OF COMMISSIONER MICHAEL J. COPPS Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 Today’s Order creates a framework for delivering emergency alerts to American mobile phones, as required by the Warning Alert Response Network (WARN) Act. Extending the nation’s emergency alert system to mobile phones is an enormous step forward. Now Americans will be able to receive warnings about dangerous weather and other imminent threats (including man-made threats like a terrorist attack) in their immediate area, even if they are not near a television set or radio and even if their electrical power is down. This is good news for all of us—especially in these dangerous times. I also think it is significant that today’s Order arises out of cooperation—through a process established by the WARN Act—among public safety representatives; government at the state, local and federal level; federally-recognized Indian tribes; industry; and national organizations representing those with special needs. For the most part, the work of the Commercial Mobile Service Alert Advisory Committee (established by the WARN Act) has been a model of how difficult and important decisions can be reached, and consensus forged, even among diverse stakeholders. The many experts who dedicated their time and energy to this important effort have made today’s decision far more informed, and responsive to technical realities, than it otherwise would be. I thank them for their service, and I hope that this spirit of cooperation and shared dedication to improving public safety can serve as a model for other public safety issues before the Commission. To be sure, there will be times when the agency cannot forge consensus and must act based on the best available evidence before it—because doing so is sometimes necessary to protect the American public. But the fact remains that the Commission and industry are both capable of reaching better outcomes when we work cooperatively, and I hope we can do so more often in the months and years ahead. Unfortunately, there is one final issue that remains unresolved by today’s Order—an issue that, if left uncorrected, threatens to vitiate it entirely. So far, no federal agency has stepped up to fulfill the unified aggregator/gateway role that virtually all stakeholders agree is necessary for our mobile alert system to work properly. Indeed, if no agency assumes this role, the rules we enact today will never become effective and Americans will never receive the protection of emergency alerts delivered to their mobile phones. The unwillingness of the Federal Emergency Management Agency (FEMA) to fulfill this role is especially disheartening because FEMA representatives were intimately involved in developing the idea of a unified Federal gateway/aggregator. In fact, not until long after the die was cast, did FEMA suggest that it would be unable for statutory and other reasons to perform this key function. Specifically, it was less than two months ago—after the advisory committee had made its recommendation and after FEMA’s representative had voted in favor of the unified Federal gateway/aggregator scheme—before FEMA raised any objection to assuming this responsibility. Federal Communications Commission FCC 08-99 66 So now we are left without a firm candidate for a position that is essential to getting this system off the ground. In light of FEMA’s recent and unexpected interpretation of its statutory authority, the Commission’s only remaining option is to work with its fellow agencies and the Congress to find a federal entity (whether FEMA, another branch of the Department of Homeland Security, or some other government agency) that can fulfill this function. I certainly wish it had not come to this. Indeed, I would not be shy about suggesting that the FCC take on this function itself—except that our agency (unlike FEMA, the Department of Justice, and the National Oceanic and Atmospheric Agency) does not currently have experience with originating emergency alerts; has not received appropriations for operating an emergency alert system (as FEMA has); and does not have statutory authority to borrow money against the DTV Transition Fund to implement the WARN Act (as the Departments of Homeland Security and Commerce have). The time may come when the FCC must consider whether to begin the task of creating this infrastructure here at our own agency, and I will not hesitate to head down this road if it looks like the fastest and most effective way to bring mobile emergency alerts to the American people. But for now the most fruitful path appears to be working with the Congress and our fellow federal agencies to see if an institution with experience originating emergency alerts is willing and able to assume this role for the CMAS system. I hope—for all of our sakes—that one will be. Federal Communications Commission FCC 08-99 67 STATEMENT OF COMMISSIONER JONATHAN S. ADELSTEIN Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 The prompt and accurate delivery of national, state and local messages to ensure the safety and security of the American people during natural or man-made disasters is critical. Today’s Report and Order marks our efforts towards ensuring that there are technologically neutral rules in place to enable commercial mobile service providers to elect to provide these critical alerts to their customers. With over 250 million subscribers of wireless services as of the end of this year, the ability of carriers to transmit emergency alerts to the public via commercial mobile devices is an urgently needed next step. One of the central purposes for the very creation of the FCC is to promote the safety of life and property of all Americans. The Commission has taken its important role in prescribing these rules very seriously, so I am pleased to support this decision. This significant step forward is due, in large part, to the dedication of state and local governments, industry and other participants that worked collaboratively to provide us with their recommendations. It is worth remembering that, as an elective system, it was vital that the rules implementing the Commercial Mobile Alert System were based upon the coordinated efforts of those that will implement and utilize this system. Collaboration, communication and cooperation have been key to this process. The effectiveness of this emergency alert system rests on the good-faith of all participating entities and I expect this will go a long way in ensuring mobile service providers elect to provide these emergency alerts. I would like to extend my sincere gratitude to the members of the Commercial Mobile Service Alert Advisory Committee who worked diligently through this important process. Federal Communications Commission FCC 08-99 68 STATEMENT OF COMMISSIONER DEBORAH TAYLOR TATE Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 With over 255 million Americans subscribing to mobile telephone service, it is critical to public safety and homeland security that the nation's emergency alert system include wireless alerts. To that end, in 2006 Congress established, via the WARN Act, a process to create a mobile emergency alert system. Today we take an important step in fulfilling this goal. I particularly wish to thank the representatives from industry; public safety providers; local, state and federal government agencies; and others who participated in the Commercial Mobile Service Alert Advisory Committee. The Federal Communications Commission should not - and in this case, can not - perform its duties without the help of such a broad coalition, especially the service providers who ultimately must transmit emergency alerts. I also wish to acknowledge Sen. Jim DeMint for his leadership in sponsoring the WARN Act and his guidance in its implementation. Finally, the excellent staff of the Public Safety and Homeland Security Bureau deserve recognition for their consistent dedication to this effort. Federal Communications Commission FCC 08-99 69 STATEMENT OF COMMISSIONER ROBERT M. MCDOWELL Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 At the outset, I want to acknowledge and thank Lisa Fowlkes, Jean Ann Collins and all of the team in the Public Safety and Homeland Security Bureau for their hard work. This project has congressionally-mandated deadlines, and they have stayed focused on their tasks to produce a great deal of excellent work in a short period of time. I also want to thank the folks from private industry and public safety who are so generously giving of their time and expertise to serve on the Commercial Mobile Service Alert Advisory Committee and participate in this important process. This project is an excellent example of the wonderful benefits that flow from a government-industry collaboration. I am pleased that the Commission has had a leading role in the meaningful partnership among the commercial wireless industry, technology providers and public safety entities. By harnessing the expertise of all interested stakeholders, we have made great strides toward the roll-out of an expanded emergency alert system. We will all benefit from the important work this group has undertaken, and I look forward to continuing to work with all of you as we complete the next set of benchmarks. At this point, the Commission is already well poised to “get out of the way” and let the private sector deliver the new alert system for the benefit of America’s wireless consumers.