E8-16853. Commercial Mobile Alert System

AGENCY:

Federal Communications Commission.

ACTION:

Final rule.

SUMMARY:

In this document, the Federal Communications Commission (Commission or FCC) adopts technical rules necessary to enable Commercial Mobile Service (CMS) alerting capability for CMS providers who elect to transmit emergency alerts to their subscribers. By adopting these rules, the Commission takes the next step in its satisfaction of the requirements of the Warning, Alert and Response Network (WARN) Act. The Commission adopts an architecture for the Commercial Mobile Alerting System (CMAS) based on the recommendations of the Commercial Mobile Service Alert Advisory Committee (CMSAAC).

DATES:

Effective September 22, 2008.

ADDRESSES:

Federal Communications Commission, 445 12th Street, SW., Room TW-A325, Washington, DC 20554.

FOR FURTHER INFORMATION CONTACT:

Jeffery Goldthorp, Communications Systems Analysis Division, Public Safety and Homeland Security Bureau, Federal Communications Commission at [phone].

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's CMAS First Report and Order in PS Docket No. 07-287, adopted and released on April 9, 2008. The complete text of this document is available for inspection and copying during normal business hours in the FCC Reference Information Center, Portals II, 445 12th Street, SW., Room CY-A257, Washington, DC 20554. This document may also be purchased from the Commission's duplicating contractor, Best Copy and Printing, Inc., in person at 445 12th Street, SW., Room CY-B402, Washington, DC 20554, via telephone at [phone], via facsimile at [phone], or via e-mail at [e-mail]. Alternative formats (computer diskette, large print, audio cassette, and Braille) are available to persons with disabilities by sending an e-mail to [e-mail] or calling the Consumer and Governmental Affairs Bureau at [phone], TTY [phone]. This document is also available on the Commission's Web site at http://www.fcc.gov.

Synopsis of the Order

1. Background. On October 13, 2006, the President signed the Security and Accountability for Every Port (SAFE Port) Act into law. 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 the Commission to undertake a series of actions to accomplish that goal, including, by December 12, 2006 (within 60 days of enactment), establishing and convening an advisory committee to recommend system critical protocols and technical capabilities for the CMAS. Accordingly, the Commission formed the CMSAAC, which had its first meeting on December 12, 2006. The WARN Act further required the CMSAAC to submit its recommendations to the Commission by October 12, 2007 (one year after enactment). The CMSAAC submitted its report on that date.

2. 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.” On December 14, 2007, the Commission released Commercial Mobile Alert System, Notice of Proposed Rulemaking, 73 FR 546, January 3, 2008, requesting comment on, among other things, the technical requirements the Commission should adopt to facilitate CMS providers' voluntary transmission of emergency alerts. The Commission 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. On April 9, 2008, the Commission adopted the CMAS First Report and Order, thus satisfying section 602(a) of the WARN Act. On July 15, 2008, the Commission released an Order on Reconsideration (FCC 08-166), in which the Commission, on its own motion, reconsidered and clarified the timeline under which the CMAS First Report and Order required CMS providers to implement the CMAS technical requirements, standards and protocols. This Order on Reconsideration revised paragraph 95 of the CMAS First Report and Order and § 10.11 of the rules adopted in the CMAS First Report and Order. These revisions are reflected in this Federal Register summary in paragraph 94 below and the rules published herein.

3. Introduction. In the CMAS First Report and Order, the Commission adopted rules necessary to enable CMS alerting capability for CMS providers who elect to transmit emergency alerts to their subscribers. Specifically, the Commission adopted the architecture for the CMAS proposed by the CMSAAC and concluded that a Federal Government entity should aggregate, authenticate, and transmit alerts to the CMS providers. In addition, the Commission adopted 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;
• 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 begin development and testing of the CMAS in a manner consistent with the rules adopted in the CMAS First Report and Order no later than 10 months from the date that the Federal Alert Aggregator and Alert Gateway makes the Government Interface Design specifications available.

4. In adopting these rules, the Commission has taken a significant step towards implementing one of its 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 the Commission has 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. The CMAS First Report and Order also is consistent with the FCC's obligation 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,” and its mandate under the Communications Act to promote the safety of life and property through the use of wire and radio communication.

5. The CMAS First Report and Order is the latest step of the Commission's 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, the Commission 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 (DBS) systems. As noted in the Further Notice of Proposed Rulemaking that accompanied the EAS First Report and Order, 70 FR 71072, November 25, 2005, wireless services are becoming equal to television and radio as an avenue to reach the American public quickly and efficiently. As of June 2007, approximately 243 million Americans subscribed to wireless services. 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.

WARN Act Section 602(a)—Technical Requirements

6. Consistent with section 602(a) of the WARN Act, the Commission adopted “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.” Specifically, the rules adopted in the CMAS First Report and Order 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. In most cases, the rules adopted are generally based on the CMSAAC recommendations. In such cases, the Commission found 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, the Commission determined that the public interest requires us to adopt requirements that are slightly different than those recommended by the CMSAAC.

7. Consideration of the CMSAAC Recommendations. Several entities representing the wireless industry generally argue in their comments that the Commission has no authority to adopt technical requirements other than those proposed by the CMSAAC and that those must be adopted “as is.” The Commission disagrees. The WARN Act does not require that the Commission adopt the CMSAAC's recommendations verbatim. Rather, Congress required the Commission to adopt relevant technical requirements “based on recommendations of the CMSAAC.” This indicates that while Congress intended that the Commission give appropriate weight to the CMSAAC's recommendations in the 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. 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.

8. 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 the Commission agrees, support Commission discretion by stating that the technical standards and requirements the Commission adopts for the CMAS should account for an evolving technology landscape. 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.

CMAS Architecture and CMS Provider Functions

9. In its recommendations, the CMSAAC proposed the following architecture for the CMAS.

Functional Reference Model Diagram

10. Under this proposed reference model, a Federal government entity, the “Alert Aggregator,” operating under a “Trust Model,” 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). The Federal government entity would also act as an “Alert Gateway” that would formulate a 90 character alert based on key fields in the CAP alert sent by the alert initiator. 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 provider to another gateway maintained by the appropriate CMS provider (CMS Provider Gateway). 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 device. 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).

11. In the CMAS NPRM, the Commission sought comment on the CMSAAC's proposed reference architecture, including its standards for defining the various element functions. 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). 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. 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.

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. 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. The Commission sought comment on this recommendation in the CMAS NPRM. The overwhelming majority of commenting parties supported the CMSAAC's recommendation. 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.”

13. The Commission adopted the CMSAAC's proposed architecture for the CMAS. It found 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 the Commission only adopt requirements for CMS providers to opt into DEAS. While the Commission agreed with CellCast that there are other potential models for alert delivery by electing CMS providers, it noted that none of those alternative solutions received the support of the CMSAAC. Moreover, the Commission noted 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.

14. Finally, The Commission disagreed 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, the Commission expected that these functions will be implemented in a reliable and redundant fashion to maximize resiliency. Furthermore, given the volume of alerts expected for the CMAS, the Commission believes that technology for processing alerts will not place a constraint on aggregator/gateway performance. Accordingly, the Commission adopted the architecture proposed by the CMSAAC. As described below, however, the Commission adopted as rules only those CMAS elements within the control of the CMS providers.

15. Federal Government Role. The Commission agreed 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, the Commission believes 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. The Commission believes that FEMA, some other entity within DHS, or NOAA may be in the best position to perform these functions. DHS, and more specifically FEMA, traditionally has been responsible for origination of Presidential alerts and administration of the EAS. 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.” 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 or avalanches), environmental (such as chemical releases or oil spills), and public safety (such as AMBER alerts or 911) warning information.

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. The Commission recognizes that FEMA asserted in its February 2008 comments that limits on its statutory authority preclude the agency from fulfilling the Federal aggregator/gateway functions. 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. The Commission noted that it was hopeful that any bars that prevent FEMA or some other entity within DHS from fulfilling these roles will be lifted expeditiously. The Commission stated its intent to work with its 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, the Commission proceeded on the assumption that a Federal agency will assume these roles at a future date. The Order is limited to adopting rules governing those sections of the CMAS architecture that are within the control of electing CMS providers. These include rules regarding the CMS Provider Gateway, CMS provider infrastructure, and CMS provider handsets. Specifically, the Commission adopted 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”). The CMS Provider Gateway will be required to, among other things: (1) Manage 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. In addition, The Commission adopted 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.

20. The Commission adopted 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. In addition, as explained below, the Commission adopted requirements for the mobile device to ensure that people with disabilities are able to receive CMAS alerts. The Commission also adopted the CMSAAC's recommendation that CMAS alerts not preempt ongoing voice or data sessions.

21. In keeping with the Commission's policy to promote technological neutrality, it declined 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. The Commission agreed 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. 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 the Commission sets forth elsewhere in this Order. For example, while the Commission includes requirements on the type of alert information that must cross the D and E interfaces to enable CMAS alerts on mobile devices, it chose to remain silent as to the precise communications protocol that a CMS provider uses to convey this information to the mobile device. This approach gives the CMS providers maximum flexibility to leverage technological innovation and implement the CMAS in a cost effective manner.

22. The Commission also adopted 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. The Commission believes that electing CMS providers expect to assemble this information, and by adopting this requirement now, it is providing direction to potential Alert Gateway providers.

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. The CMSAAC also recommended CAP-based mapping parameters.

24. The Commission supports 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 the Commission adopts in this docket. The Commission declines, however, to codify these protocols and specifications in this Order. It believes 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, the Commission concludes that final determination of these interface protocols is better left to industry standards organizations. The Commission noted that it will revisit this matter in the future if Commission action in this area is indicated.

General CMAS Requirements

25. In this section, the Commission establishes the basic regulatory framework of the new CMAS. Specifically, it adopts 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.

26. Scope and Definition of CMAS Alerts. The WARN Act requires the Commission to enable commercial mobile alerting capabilities for “emergency” alerts, but does not define what may comprise an emergency. Accordingly, in the CMAS NPRM, the Commission sought comment on the appropriate scope of emergency alerts, including whether and to what extent alerts should be classified. The Commission specifically asked parties to address whether it 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. For the reasons stated below, the Commission finds that the public interest will be best served by its adopting these three alert classes, which it defines below.

27. The Commission agrees 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. Alert Systems however argues that the Commission should include additional classes of alerts, such as traffic advisories. The Commission finds 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. The Commission believes 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. The Commission also notes 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. Accord-ingly, the Commission rejects arguments to broadly define eligible alert classes beyond those specified here.

28. Presidential Alerts. 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.” 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.” 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. Further, Presidential Alerts must be transmitted upon receipt by a CMS provider, without any delay, and therefore will preempt any other pending alert. The Commission notes that due to the initial 90-character text message protocol that it is adopting below for the first generation CMAS, 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.”

29. Imminent Threat Alerts. The Commission notes that virtually all commenting parties support adoption of the CMSAAC's recommendation to define an Imminent Threat Alert class. 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).
• 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).
• 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). That is, the event must have occurred, or be occurring (Observed), or be more likely to occur than not (Likely).

30. The Commission finds 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. As T-Mobile correctly states, CMAS alerts are not appropriate for warning the public about minor events. 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, the Commission finds it appropriate to require participating CMS providers to transmit Imminent Threat Alerts.

31. Child Abduction Emergency/AMBER Alerts. 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. There are four types of AMBER Alerts: (1) Family Abduction, (2) Nonfamily Abduction, (3) Lost, Injured, or Otherwise Missing, and Endangered Runaway. 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. The Commission also notes that a number of CMS providers currently transmit AMBER Alerts using Short Message Service (SMS) technology, and applauds their potentially life-saving efforts in this regard.

32. In 2006, 261 AMBER Alerts were issued in the United States involving 316 children. Most of these alerts were issued on an intrastate basis. 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. Based on the limited number of AMBER alerts and their confined geographic scope, the Commission does not expect such alerts to be overly burdensome to CMS providers that participate in the CMAS. Moreover, because of the efficacy of AMBER Alerts, the Commission finds that the public interest in the safety of America's children will be well served by the provision of AMBER Alerts by the wireless industry. Accordingly, the Commission requires participating CMS providers to transmit AMBER alerts.

33. Technologically Neutral Alert System. 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.” The Commission agrees. 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. Consistent with the Commission's well-established policy of technologically-neutral regulation of the wireless telecommunications industry, it believes 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, the Commission does not limit the range of technologies that electing CMS providers may deploy to participate in the CMAS. In reaching this conclusion, the Commission balances the alerting needs of the public and the capabilities of electing CMS providers and the Commission's mandate under section 602(a) of the WARN Act to enable the provision of emergency alerts. The Commission emphasizes 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. 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. 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. The Commission notes that many of the requirements that it adopts 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. The Commission foresees that as CMS providers gain experience 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, the Commission will not prohibit their use if a CMS provider can otherwise meet the requirements that the Commission establishes. Short Message Service (SMS) 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. The Commission recognizes, 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.

36. The CMSAAC noted that technologies such as MediaFLO and DVB-H “may provide supplemental alert information,” but recommended that they should not be considered as part of the CMAS. The Commission's goal in this proceeding is to enable the broadest possible voluntary participation in the CMAS, and it 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. 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. Moreover, a number of parties have expressed reservations about these technologies. Nonetheless, in keeping with its overall policy to maintain technological neutrality, the Commission does not require or prohibit the use of ALERT-FM, RBDS or similar systems as the basis of the CMAS.

38. The Commission also strongly encourages fair, reasonable, and nondiscriminatory Intellectual Property Rights (IPR) licensing in the context of the CMAS. It agrees with the CMSAAC that the technical standards, protocols, procedures, and related requirements that the Commission adopts pursuant to section 602(a) of the WARN Act should be standardized in industry bodies that have well defined IPR policies. The Commission declines, 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.” The Commission also declines to require “all participants in the public comment process on th[e] CMAS Architecture and Requirements document” to make such a written assurance. These requests are outside the scope of section 602(a) of the WARN Act.

39. The CMSAAC made a number of additional recommendations that the Commission concludes are outside the scope of its 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. Specifically, the CMSAAC submitted recommendations regarding the applicability of requirements for location, number portability and the Communications Assistance for Law Enforcement Act (CALEA). 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. The Commission finds that these issues are outside the scope of section 602(a) of the WARN Act and, therefore, does not address these issues in the Order.

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.” The Commission agrees and believes 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, the Commission agrees 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, the Commission 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.” Finally, the Commission agrees that electing CMS providers should have discretion regarding whether certain devices, such as laptop wireless data cards, will support alerting capabilities.

CMAS Message Elements and Capabilities

41. Required Alert Message Elements. 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. 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

42. The CMSAAC proposed this format to facilitate CAP value field mapping to text. It also noted that the format would likely evolve as experience is gained by alert initiators and by electing CMS providers. In the CMAS NPRM, the Commission sought comment on the five elements and asked parties to address whether the elements are consistent with accepted industry practices for emergency alerts.

43. 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.” 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. Based on the Commission's review of the record, it finds that on balance the five message elements identified above will enable standardization of alerting messages and adopts them. The Commission rejects 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 messages.” A biohazard or flash flood warning, for example, would not enable the public to avoid a lethal hazard without appropriate area affected information. The Commission also expects that as CMAS providers eventually deploy technologies capable of messages of more than 90 characters, additional alert message elements will be implemented.

44. In the CMAS NPRM, the Commission also sought comment on whether alert messages should include telephone numbers, URLs or other response and contact information, including any related network impacts. The CMSAAC advised against inclusion of URLs or telephone numbers because such information would encourage mass access of wireless networks. The California Public Utility Commission (CAPUC) supports inclusion of a sixth message element for URLs, if feasible. 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. The Commission finds 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. The Commission therefore will not require participating CMS providers to accept or transmit any alert message that contains an embedded URL or telephone number.

45. CMAS Generation of Free Text Alert Messages. In the CMAS NPRM, the Commission 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. The CMSAAC recommended this approach for initial system deployments. The Commission also sought comment on the CMSAAC's recommendation to allow the generation of free text for Presidential and AMBER alert messages. 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. 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.” The Commission agrees 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.

46. CellCast argues that the Commission should “ignore” the CMSAAC recommendations regarding alert generation, asserting that message generation is beyond its mandate under the WARN Act. 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, the Commission supports the CMSAAC's recommended approach of allowing the Alert Gateway to create messages using CAP fields and SAME codes. Specifically, the Commission believes that this approach would enable the provision of consistent and accurate messages to the public, while facilitating future enhancements to the Alert Gateway.

47. The Commission also agrees 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. 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.” The Commission thus believes that the public interest would be served if the CMAS architecture accommodates free-form text messaging, subject to the 90-character text limit that it adopts and its 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. The Commission also agrees with the CMSAAC that free-form text should be included as a CAP message parameter.

48. Finally, the Commission concurs with the CMSAAC that automatic text generation at the Alert Gateway would be impractical for Presidential or AMBER Alerts, 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. Accordingly, the Commission finds that law enforcement authorities should have the ability to formulate unique message text for the dissemination of AMBER Alerts via the CMAS. The Commission envisions 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, it agrees 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.”

49. Geo-targeting CMAS Alerts. 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.” The Commission, based on the substantial record before it, and for the reasons stated below, requires electing CMS providers to geographically target (geo-target) alerts accordingly. The Commission notes that radio frequency (RF) propagation areas for some paging systems and cell sites may exceed a single county, and will permit geo-targeting that exceeds county boundaries in these limited circumstances.

50. 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.” The Commission stands ready to work with DHS and NIST to facilitate this important undertaking. The Commission fully expects 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 the Commission strongly encourages them to do so. As T-Mobile notes, electing CMS providers should be free to target more specifically, subject to the liability protections of the WARN Act.

51. In the CMAS NPRM, the Commission sought comment on what level of precision it should require for geo-targeting, considering the CMSAAC's recommendation for county-level geo-targeting. 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 Initiator.” 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.” 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.

52. 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. Purple Tree Technologies asserts that sub-county targeting is “possible with cell broadcast,” and that there are few technical hurdles preventing granular alerts. Acision and CellCast both contend that cell broadcast technology would allow for targeting to the individual cell level. DataFM claims its technology could target “specific geographic areas without regard to the location of its transmitters.”

53. 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. NENA asserts that targeting messages to the block level (similar to emergency telephone notification systems) would be “ideal,” but recognizes this is not possible. The CAPUC argues that county targeting would be overbroad for most emergencies, and urges ZIP-code level targeting. The Commission notes that there are more than 40,000 active ZIP codes in the United States, and many of these are assigned to specific addresses. The CAPUC does not explain how ZIP code targeting could be implemented.

54. 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. T-Mobile agrees that electing CMS providers should not be 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. Alltel also supports county-level targeting, but states that it intends to target more granularly.

55. 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. 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. 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.

56. Based on the foregoing, and subject to the limited exception discussed below, the Commission concludes that it would be premature for it generally to require targeting of alerts more precisely than the county level. The Commission specifically notes 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, 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, at this point the Commission finds 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.

57. Accordingly, the Commission generally requires CMS providers that elect to participate in the CMAS to geographically target emergency alerts to the county level. In adopting this rule, the Commission recognizes 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, the Commission will permit the RF signal carrying the alert to extend beyond a county's boundaries. Electing CMS providers may 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, the Commission will address this recommendation once an entity has been identified to provide the Alert Aggregator and Gateway functions.

58. Meeting the Needs of Users, Including Individuals with Disabilities and the Elderly. 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. 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,” the CMSAAC concluded, and the Commission agrees, that Congress intended to include the elderly and those with disabilities among the class to which electing CMS providers are to deliver alerts. Accordingly, the Commission concludes that CMAS access to those with disabilities and the elderly falls within its 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.

59. 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. The CMSAAC recommended that both functions be distinct from any other device alerts and restricted to use for commercial mobile alerting purposes. The CMSAAC further noted that these features would benefit not only individuals with disabilities and the elderly, but also subscribers more generally.

60. 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. For devices with only a single frequency capability, the CMSAAC recommended an audio attention signal below 2 kHz. The CMSAAC also recommended that the unique vibration cadence should be noticeably different from the default cadence of the handset. The CMSAAC further recommended that if a device includes both the audio and vibration functions, simultaneous activation of both functions should not be required and that configuration should be determined by end users.

61. In the CMAS NPRM, the Commission sought comment on the CMSAAC recommendations, including any technical or accessibility requirements that the Commission should adopt to ensure that commercial mobile alerts will be received by individuals with disabilities and the elderly. The Commission asked whether attention signals should be required for all users. It 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.

62. 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. Alert Systems likewise notes that “[u]rgency coding of messages is vital,” and that caretakers and operators of certain industrial facilities in particular “need unique alert tone patterns/amplitudes to quickly reprioritize activities.”

63. The Wireless Rehabilitation Engineering Research Center for Wireless Technologies (Wireless RERC) supports adoption of a common audio attention signal, and recommends that the Commission 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. 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. AAPC supports the CMSAAC recommendations, but states that legacy devices should not be required to support such functions. 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. DataFM notes 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.

64. 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. 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.

65. The Commission agrees with the majority of those commenting and the CMSAAC that it is vital that the Commission ensures access to commercial mobile alerts by individuals with disabilities and the elderly. The Commission disagrees 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.

66. Accordingly, to address the needs of these user groups and the needs of users more generally, the Commission 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. Specifically, as the CMSAAC recommended, the Commission specifies 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. The Commission also requires that the entire sequence be repeated twice with a half (0.5) second interval between repetitions. For devices with polyphonic capabilities, the Commission adopts 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, the Commission requires that a universal audio attention signal be of 960 Hz (the higher frequency EAS tone).

67. The Commission also seeks 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 adopts the same temporal pattern for the vibration cadence as the CMSAAC recommended that the Commission specify for the audio attention signal. The Commission strongly encourages CMS providers to coordinate with device manufacturers to utilize existing technologies to comply with these requirements as soon as possible.

68. The Commission recognizes that incorporating capabilities for a common audio attention signal and a common vibration cadence on the many devices that it expects to be offered to the public will take time to develop and implement successfully. However, the Commission believes 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.

69. Output Mode/Display. The CMSAAC issued several recommendations regarding the output mode/display of mobile devices. Specifically, the CMSAAC recommended that CMAS-enabled mobile devices should employ display fonts that are easily readable with recognizable characters, citing three typeface examples. MetroPCS notes that certain accessibility requirements already apply to CMS providers, and that CMAS-enabled mobile devices will therefore accommodate certain disabilities. 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. Although the Commission agrees with the CMSAAC that “the goal in font selection is to use easily recognizable characters,” it does 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, the Commission does not limit the display of CMAS alerts to a particular font or character set.

70. Text-to-speech (TTS) enabled wireless mobile devices are becoming increasingly common, and the Commission strongly encourages 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. The Commission notes that many of the requirements that it adopts for the first generation of CMAS are intended to enable the provision of text-based alerts to the public. Although the Commission envisions that the CMAS will evolve to include audio and video service profiles, it finds 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.

71. Message Retransmission. The Commission agrees with the CMSAAC that alerts should be retransmitted periodically to an affected area until their specified expiration. 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), 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. The Commission agrees with this assessment and adopts this recommendation as reasonable for the initial implementation of the CMAS. As the system is deployed, the Commission may wish to revisit the issue to see if a consistent, industry-wide alert retransmission interval would be more appropriate.

72. Multi-Language CMAS Alerting. 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.” In the CMAS NPRM, the Commission sought comment on the technical feasibility of providing commercial mobile alerts in languages in addition to English, including how the provision of alerts in multiple languages could affect the generation and distribution of messages on a local, state, and national level. Based on the record before us, the Commission finds that it would be premature to require CMS providers to transmit alerts in languages in addition to English. As explained below, the Commission agrees with the CMSAAC and those commenters that state that further technical study is needed to enable the provision of alerts in multiple languages.

73. 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. 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. The CMSAAC stated that delivering CMAS alerts in these languages would require mobile devices capable of supporting at least 16 different character sets. 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. 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.

74. 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,” and that the State “uses different languages for different types of communications * * * [including] Spanish, Cantonese, Mandarin, Tagalog, Vietnamese, Korean, Farsi, Arabic, and Hmong.” The CAPUC asserts “that various commercial alert service providers represent that they can provide alerts in six different languages,” 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 the Commission therefore cannot adopt CAPUC's request that the Commission require transmission of alerts in a minimum of six languages.

75. 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. CellCast suggests that such standards would provide clear direction for international harmonization of emergency alerting systems and handsets. 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. 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. One2many states that there are numerous “channels,” or Message Identifiers, available in a cell broadcast. According to One2many, end users can activate their phones to receive messages on the channel number that matches their language.

76. 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 the Commission 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. 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. According to Alltel, GSM can support multiple channels for simultaneous broadcast and discrete channels could be dedicated to different languages. 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.

77. 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. 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. 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.

78. 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. The CAPUC, which advocates mandatory multi-language alerting, urges the Commission to examine whether latency or delivery concerns could be resolved if language receipt were part of a pre-subscription process. The Wireless RERC asks that the Commission 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. 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, the Commission concludes that further study is needed to develop capabilities for providing alerts in multiple languages, and does not require provision of alerts in any language other than English at this time. The Commission encourages the wireless industry and the public safety community to expeditiously develop and implement capabilities to deliver alerts in languages in addition to English.

79. Roaming. The Commission agrees 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. As discussed further below, the Commission finds that adopting such a requirement is consistent with its responsibility under the WARN Act to enable commercial mobile service alerting, as well as its 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.”

80. 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.” 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 the Commission adopts, 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 alert messages, provided the subscriber's mobile device is configured for and technically capable of receiving alert messages from the roamed upon network.

81. Preemption of Calls in Progress. The CMSAAC recommended that CMAS alerts not preempt ongoing voice or data sessions. The Commission agrees with this recommendation. It believes 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, the Commission will require that any device marketed as “CMAS compliant” must not permit an alert to preempt an ongoing call.

82. Service Profiles. 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. 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, the Commission sought comment on the service profiles recommended by the CMSAAC. The Commission agrees with those commenters who argue that it should adopt the CMSAAC's recommendation that text-only alerts are appropriate for an initial system. Because the Commission believes that it would be premature and not consistent with its 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.

83. As part of the text profile, the CMSAAC recommended a maximum displayable message size of 90 characters. The Commission sought comment on this recommendation in the CMAS NPRM. 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 * * *” 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. AAPC states that the 90 character limit strikes an appropriate balance between complexity and a reasonably constructed CMAS. 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. 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.”

84. The Commission concludes that, at this initial stage, adoption of a 90 character limit serves the public interest. The Commission agrees 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. 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.

85. 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. The Commission agrees 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. Rather, related files or other resource elements must be provided separately by the Alert Gateway to the CMS Provider Gateway.

86. The Commission also adopts the CMSAAC observation that the CMAS profiles will not be able to accommodate real-time content, including a Presidential alert, even in text format. The Commission believes 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 radio and television station and other mass media is the best option for obtaining additional emergency information.

87. The text profiles the Commission adopts are reflected in table below:

Text Profile

Attribute Name	Attribute Definition	Note
Service Profile: Text_Universal_Service_Profile
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.

88. Security for CMAS Alerts. 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.

89. The Commission finds that an IP-based communications across the “C” interface serves the public interest because it would enhance the security of the CMAS. Accordingly, the Commission adopts the CMSAAC's recommendation. It disagrees 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. Rather, the Commission agrees with Verizon Wireless, which in its Reply Comments rejects such a need. As Verizon Wireless correctly points out, under the CMAS Reference Architecture, which the Commission has 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 alert initiators. 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.

90. 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 the Commission believes 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 the Commission adopt technical requirements necessary to facilitate emergency alert capabilities of CMS providers. Accordingly, the Commission adopts this recommendation of the CMSAAC.

91. CMAS Reliability and Performance. 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.

92. 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, the Commission cannot adopt rules in this area at this time.

93. Timeline for Implementation of Technical Requirements, Standards and Protocols. 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. 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.

94. At the outset the Commission notes that the majority of commenters that addressed the issue supported the CMSAAC's proposed deployment timeline. 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.

95. 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, the Commission agrees 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.

96. The Federal Alert Aggregator and Alert Gateway will make the Government Interface Design specifications available. In accordance with the CMSAAC proposed timeline, CMS providers must begin development and testing of the CMAS in a manner consistent with the rules adopted in the CMAS First Report and Order no later than 10 months from the date that the Alert Aggregator/Alert Gateway makes the Government Interface Design specifications available. This time period is consistent with the 10 months the CMSAAC proposed timeline indicates would elapse between the availability of the Aggregator/Gateway interface design specification and the beginning of CMAS development and testing. The Commission believes that this will give the government and industry stakeholders sufficient time to begin development, including the federal government's role. It will also give electing CMS providers adequate time to come into compliance with the rules adopted herein.

Procedural Matters

A. Final Paperwork Reduction Act 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, the Commission notes that pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), the Commission 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. Report to Congress

98. The Commission will send a copy of the CMAS First 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).

Final Regulatory Flexibility Analysis

99. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), 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). In addition, the CMAS NPRM and IRFA were published in the Federal Register.

Need for, and Objectives of, the Order

100. 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.” 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), the CMAS First Report and Order only addresses issues raised by section 602(a) of the WARN Act. 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.

101. The 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.

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

102. 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. 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 outside of the scope of this Order.

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

103. 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. The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act. 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).

104. Wireless Telecommunications Carriers (except Satellite). Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category. 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.” 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, the Commission estimates 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. Of this total, 804 firms had employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more. 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. Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 1,000 employees or more. Thus, using the prior categories and the available data, the Commission estimates that the majority of wireless firms can be considered small.

105. Cellular Service. As noted, the SBA has developed a small business size standard for small businesses in the category “Wireless Telecommunications Carriers (except satellite).” Under that SBA category, a business is small if it has 1,500 or fewer employees. Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category. 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.” Accordingly, the pertinent data for this category is contained within the prior Wireless Telecommunications Carriers (except Satellite) category.

106. Auctions. Initially, the Commission notes 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.

107. 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. For Block F, an additional small 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. These small business size standards, in the context of broadband PCS auctions, have been approved by the SBA. 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. On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block licenses; there were 113 small business winning bidders. On January 26, 2001, the Commission completed the auction of 422 C and F PCS licenses in Auction 35. 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.

108. 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. Through these auctions, the Commission awarded a total of forty-one licenses, 11 of which were obtained by four small businesses. 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. 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. A “very 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 $15 million. The SBA has approved these small business size standards. A third auction commenced on October 3, 2001 and closed on October 16, 2001. Here, five bidders won 317 (MTA and nationwide) licenses. Three of these claimed status as a small or very small entity and won 311 licenses.

109. 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. The SBA has approved these definitions. 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.

110. 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. 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. 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. SBA approval of these definitions is not required. 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. Of the 104 licenses 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. 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). 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. Accordingly, at this time there are 54 licenses in the 700 MHz Guard Bands.

111. 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. 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. The SBA has approved these small size standards.

112. 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. A second auction commenced on May 28, 2003, and closed on June 13, 2003, and included 256 licenses: Five EAG licenses and 251 CMA licenses. 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.

113. 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.”

114. 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. 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. 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.

115. 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).” 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. 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.” 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, the Commission 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. Of this total, 804 firms had employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more. 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. Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 1,000 employees or more. Thus, using the prior categories and the available data, the Commission estimates that the majority of wireless firms can be considered small. Thus, under this category, the majority of firms can be considered small.

116. In the Paging Third Report and Order, the Commission 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. 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. The SBA has approved these small business size standards. An auction of Metropolitan Economic Area licenses commenced on February 24, 2000, and closed on March 2, 2000. 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. Of those, the Commission estimates that 360 are small, under the SBA-approved small business size standard.

117. Wireless Communications Service. This service can be used for fixed, mobile, radiolocation, and digital audio broadcasting satellite uses. The Commission established small business size standards for the wireless communications services (WCS) auction. 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. 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.

118. Wireless Communications Equipment Manufacturers. While these entities are merely indirectly affected by its action, the Commission describes 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. 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.

119. 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.” 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. 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.

120. Software Publishers. While these entities are merely indirectly affected by its action, the Commission is 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, the Commission estimates that the majority of the firms in this category are small entities that may be affected by its action.

121. 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.” 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. 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. The Commission notes, however, that in assessing whether a business concern qualifies as small under the above definition, business (control) affiliations must be included. The Commission's estimate, therefore, likely overstates the number of small entities that might be affected by the Commission's action, because the revenue figure on which it is based does not include or aggregate revenues from affiliated companies.

122. In addition, an element of the definition of “small business” is that the entity not be dominant in its field of operation. The Commission is unable at this time to define or quantify the criteria that would establish whether a specific television station is dominant in its field of operation. Accordingly, the estimate of small businesses to which rules may apply do not exclude any television station from the definition of a small business on this basis and are therefore over-inclusive to that extent. Also as noted, an additional element of the definition of “small business” is that the entity must be independently owned and operated. The Commission notes that it is difficult at times to assess these criteria in the context of media entities and its 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). Given the nature of this service, the Commission will presume that all LPTV licensees qualify as small entities under the above SBA small business size standard.

123. The Commission has, under SBA regulations, estimated the number of licensed NCE television stations to be 380. The Commission notes, however, that, in assessing whether a business concern qualifies as small under the above definition, business (control) affiliations must be included. The Commission's estimate, therefore, likely overstates the number of small entities that might be affected by its 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.

Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements

124. 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, the Commission notes that pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), the Commission previously sought specific comment on how the Commission might “further reduce the information collection burden for small business concerns with fewer than 25 employees.

Steps Taken To Minimize the Significant Economic Impact on Small Entities, and Significant Alternatives Considered

125. 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.”

126. As noted above, the CMAS First Report and Order deals only with the WARN Act section 602(a) requirement that the Commission adopt technical standards, 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 the Commission indicates by its treatment of the comments of Interstate Wireless above, the technical requirements, standards and protocols on which the Commission sought comment already contain concerns raised by small businesses. The WARN ACT NPRM also sought comment on a number of alternatives to the recommendations of the CMSAAC, such as the Digital EAS and FM sub-carrier based alerts. 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 the Commission's goal of advancing its 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 the Commission anticipates that the standards, protocols and requirement that it adopts in this Order will encourage CMS providers to work with other industry and government entities to complete and participate in the CMAS.

Federal Rules That May Duplicate, Overlap, or Conflict with the Proposed Rules

127. None.

Report to Congress

128. The Commission will send a copy of the Order, including this FRFA, in a report to be sent to Congress pursuant to the Congressional Review Act. In addition, the Commission will send a copy of the Order, including this FRFA, to the Chief Counsel for Advocacy of the SBA. A copy of this present summarized Order and FRFA is also hereby published in the Federal Register.

Ordering Clauses

129. 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 September 22, 2008, except that any new information collection requirements contained in these rules will not become effective prior to OMB approval. The Commission will publish a document in the Federal Register announcing the effective date of any information collections.

130. 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.

List of Subjects in 47 CFR Part 10

• Alert and warning
• AMBER alert
• Commercial mobile service provider

Federal Communications Commission.

Marlene H. Dortch,

Secretary.

Final Rules

For the reasons discussed in the preamble, the Federal Communications Commission amends 47 CFR chapter I by adding Part 10 to read as follows:

PART 10—COMMERCIAL MOBILE ALERT SYSTEM

Subpart A—General Information

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

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

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

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]

Authority: 47 U.S.C. 151, 154(i) and (o), 201, 303(r), 403, and 606; sections 602(a), (b), (c), (f), 603, 604 and 606 of Pub. L. 109-347, 120 Stat. 1884.

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, Public Law 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 FR 36975, June 26, 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 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.

(e) 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; 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 begin development and testing of the CMAS in a manner consistent with the rules in this part no later than 10 months from the date that the Federal Alert Aggregator and Alert Gateway makes the Government Interface Design specifications available.

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.

(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.

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	<yes/no>	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.

(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. (1) 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:

(i) Law enforcement confirms a child has been abducted;

(ii) The child is 17 years or younger;

(iii) Law enforcement believes the child is in imminent danger of serious bodily harm or death;

(iv) There is enough descriptive information about the victim and the abduction to believe an immediate broadcast alert will help; and

(v) The child's name and other data have been entered into the National Crime Information Center.

(2) There are four types of AMBER Alerts: Family Abduction; Non-family Abduction; Lost, Injured or Otherwise Missing; and Endangered Runaway.

(i) 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.

(ii) 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.

(iii) 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.

(iv) 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 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 this chapter), 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.

§ 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]