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