[Federal Register Volume 73, Number 143 (Thursday, July 24, 2008)]
[Rules and Regulations]
[Pages 43099-43120]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: E8-16853]


=======================================================================
-----------------------------------------------------------------------

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Part 10

[PS Docket No. 07-287; FCC 08-99]


Commercial Mobile Alert System

AGENCY: Federal Communications Commission.

ACTION: Final rule.

-----------------------------------------------------------------------

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

DATES: Effective September 22, 2008.

[[Page 43100]]


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

FOR FURTHER INFORMATION CONTACT: Jeffery Goldthorp, Communications 
Systems Analysis Division, Public Safety and Homeland Security Bureau, 
Federal Communications Commission at (202) 418-1096.

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

Synopsis of the Order

    1. Background. On October 13, 2006, the President signed the 
Security and Accountability for Every Port (SAFE Port) Act into law. 
Title VI of the SAFE Port Act, the Warning Alert and Response Network 
(WARN) Act, establishes a process for the creation of the CMAS whereby 
CMS providers may elect to transmit emergency alerts to their 
subscribers. The WARN Act requires the Commission to undertake a series 
of actions to accomplish that goal, including, by December 12, 2006 
(within 60 days of enactment), establishing and convening an advisory 
committee to recommend system critical protocols and technical 
capabilities for the CMAS. Accordingly, the Commission formed the 
CMSAAC, which had its first meeting on December 12, 2006. The WARN Act 
further required the CMSAAC to submit its recommendations to the 
Commission by October 12, 2007 (one year after enactment). The CMSAAC 
submitted its report on that date.
    2. Section 602(a) of the WARN Act further requires that, by April 
9, 2008 (within 180 days of receipt of the CMSAAC's recommendations), 
the Commission complete a proceeding to adopt ``relevant technical 
standards, protocols, procedures and technical requirements'' based on 
recommendations submitted by the CMSAAC, ``necessary to enable 
commercial mobile service alerting capability for commercial mobile 
service providers that voluntarily elect to transmit emergency 
alerts.'' On December 14, 2007, the Commission released Commercial 
Mobile Alert System, Notice of Proposed Rulemaking, 73 FR 546, January 
3, 2008, requesting comment on, among other things, the technical 
requirements the Commission should adopt to facilitate CMS providers' 
voluntary transmission of emergency alerts. The Commission specifically 
invited comment on the CMSAAC's proposed technical requirements. 
Comments were due on February 4, 2008, with Reply Comments due on 
February 19, 2008. On April 9, 2008, the Commission adopted the CMAS 
First Report and Order, thus satisfying section 602(a) of the WARN Act. 
On July 15, 2008, the Commission released an Order on Reconsideration 
(FCC 08-166), in which the Commission, on its own motion, reconsidered 
and clarified the timeline under which the CMAS First Report and Order 
required CMS providers to implement the CMAS technical requirements, 
standards and protocols. This Order on Reconsideration revised 
paragraph 95 of the CMAS First Report and Order and Sec.  10.11 of the 
rules adopted in the CMAS First Report and Order. These revisions are 
reflected in this Federal Register summary in paragraph 94 below and 
the rules published herein.
    3. Introduction. In the CMAS First Report and Order, the Commission 
adopted rules necessary to enable CMS alerting capability for CMS 
providers who elect to transmit emergency alerts to their subscribers. 
Specifically, the Commission adopted the architecture for the CMAS 
proposed by the CMSAAC and concluded that a Federal Government entity 
should aggregate, authenticate, and transmit alerts to the CMS 
providers. In addition, the Commission adopted technologically neutral 
rules governing:
     CMS provider-controlled elements within the CMAS 
architecture (e.g., the CMS Provider Gateway, CMS Provider 
infrastructure and mobile devices);
     Emergency alert formatting, classes, and elements: 
Participating CMS Providers must transmit three classes of alerts--
Presidential, Imminent Threat, and AMBER alerts;
     Geographic targeting (geo-targeting): Participating CMS 
Providers generally are required to target alerts at the county-level 
as recommended by the CMSAAC;
     Accessibility for people with disabilities and the 
elderly: Participating CMS Providers must include an audio attention 
signal and vibration cadence on CMAS-capable handsets;
     Multi-language Alerting: Participating CMS Providers will 
not be required at this time to transmit alerts in languages other than 
English;
     Availability of CMAS alerts while roaming: Subscribers 
receiving services pursuant to a roaming agreement will receive alert 
messages on the roamed upon network if the operator of the roamed upon 
network is a Participating CMS provider and the subscriber's mobile 
device is configured for and technically capable of receiving alert 
messages from the roamed upon network;
     Preemption of calls in progress: CMAS alerts may not 
preempt a voice or data session in progress;
     Initial implementation: Participating CMS Providers must 
begin development and testing of the CMAS in a manner consistent with 
the rules adopted in the CMAS First Report and Order no later than 10 
months from the date that the Federal Alert Aggregator and Alert 
Gateway makes the Government Interface Design specifications available.
    4. In adopting these rules, the Commission has taken a significant 
step towards implementing one of its highest priorities--to ensure that 
all Americans have the capability to receive timely and accurate 
alerts, warnings and critical information regarding disasters and other 
emergencies irrespective of what communications technologies they use. 
As the Commission has learned from disasters such as the 2005 
hurricanes, such a capability is essential to enable Americans to take 
appropriate action to protect their families and themselves from loss 
of life or serious injury. The CMAS First Report and Order also is 
consistent with the FCC's obligation under Executive Order 13407 to 
``adopt rules to ensure that communications systems have the capacity 
to transmit alerts and warnings to the public as part of the public 
alert and warning system,'' and its mandate under the Communications 
Act to promote the safety of life and property through the use of wire 
and radio communication.
    5. The CMAS First Report and Order is the latest step of the 
Commission's ongoing drive to enhance the reliability, resiliency, and 
security of emergency alerts to the public by requiring that

[[Page 43101]]

alerts be distributed over diverse communications platforms. In the 
2005 EAS First Report and Order, the Commission expanded the scope of 
the Emergency Alert System (EAS) from analog television and radio to 
include participation by digital television broadcasters, digital cable 
television providers, digital broadcast radio, Digital Audio Radio 
Service (DARS), and Direct Broadcast Satellite (DBS) systems. As noted 
in the Further Notice of Proposed Rulemaking that accompanied the EAS 
First Report and Order, 70 FR 71072, November 25, 2005, wireless 
services are becoming equal to television and radio as an avenue to 
reach the American public quickly and efficiently. As of June 2007, 
approximately 243 million Americans subscribed to wireless services. 
Wireless service has progressed beyond voice communications and now 
provides subscribers with access to a wide range of information 
critical to their personal and business affairs. In times of emergency, 
Americans increasingly rely on wireless telecommunications services and 
devices to receive and retrieve critical, time-sensitive information. A 
comprehensive wireless mobile alerting system would have the ability to 
alert people on the go in a short timeframe, even where they do not 
have access to broadcast radio or television or other sources of 
emergency information. Providing critical alert information via 
wireless devices will ultimately help the public avoid danger or 
respond more quickly in the face of crisis, and thereby save lives and 
property.

WARN Act Section 602(a)--Technical Requirements

    6. Consistent with section 602(a) of the WARN Act, the Commission 
adopted ``technical standards, protocols, procedures and other 
technical requirements * * * necessary to enable commercial mobile 
service alerting capability for commercial mobile service providers 
that voluntarily elect to transmit emergency alerts.'' Specifically, 
the rules adopted in the CMAS First Report and Order address the CMS 
providers' functions within the CMAS, including CMS provider-controlled 
elements within the CMAS architecture, emergency alert formatting, 
classes and elements, geographic targeting (geo-targeting) and 
accessibility for people with disabilities and the elderly. In most 
cases, the rules adopted are generally based on the CMSAAC 
recommendations. In such cases, the Commission found that the CMSAAC's 
recommendations are supported by the record and that adoption of those 
recommendations serves the public interest and meets the requirements 
of the WARN Act. For reasons discussed below, however, in some cases, 
the Commission determined that the public interest requires us to adopt 
requirements that are slightly different than those recommended by the 
CMSAAC.
    7. Consideration of the CMSAAC Recommendations. Several entities 
representing the wireless industry generally argue in their comments 
that the Commission has no authority to adopt technical requirements 
other than those proposed by the CMSAAC and that those must be adopted 
``as is.'' The Commission disagrees. The WARN Act does not require that 
the Commission adopt the CMSAAC's recommendations verbatim. Rather, 
Congress required the Commission to adopt relevant technical 
requirements ``based on recommendations of the CMSAAC.'' This indicates 
that while Congress intended that the Commission give appropriate 
weight to the CMSAAC's recommendations in the adoption of rules, it did 
not intend to require the Commission to adopt the CMSAAC's 
recommendations wholesale, without any consideration for views 
expressed by other stakeholders in the proceeding or the need to 
address other significant policy goals. Moreover, adopting the CMSAAC's 
recommendations in their entirety, without scrutiny, would result in an 
abdication of the Commission's statutory mandate under the 
Communications Act to act in the public interest. Clearly the WARN Act 
did not delegate Commission authority under the Communications Act to 
an advisory committee; on the contrary, the Commission was to conclude 
a ``proceeding'' which necessarily implicates notice and an opportunity 
for public comment, and Commission discretion in adopting appropriate 
rules and requirements.
    8. Commission discretion and flexibility in its adoption of the 
CMSAAC recommendations is also supported by the policy goal underlying 
the WARN Act, i.e., the creation of a CMAS in which CMS providers will 
elect to participate, and which will effectively deliver alerts and 
warnings to the public. The comments of Ericsson, with which the 
Commission agrees, support Commission discretion by stating that the 
technical standards and requirements the Commission adopts for the CMAS 
should account for an evolving technology landscape. In order to 
account for changes in the wireless industry and maintain a 
technologically neutral approach to emergency alerting, the Commission 
must be able to apply the CMSAAC's recommendations to new technologies 
and services. A reasonable interpretation of the WARN Act, therefore, 
is that the Commission has the discretion to evaluate the CMAS 
technical requirements recommended by the CMSAAC.

CMAS Architecture and CMS Provider Functions

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

Functional Reference Model Diagram

[[Page 43102]]

[GRAPHIC] [TIFF OMITTED] TR24JY08.001

    10. Under this proposed reference model, a Federal government 
entity, the ``Alert Aggregator,'' operating under a ``Trust Model,'' 
would receive, aggregate, and authenticate alerts originated by 
authorized alert initiators (i.e., Federal, state, tribal and local 
government agencies) using the Common Alerting Protocol (CAP). The 
Federal government entity would also act as an ``Alert Gateway'' that 
would formulate a 90 character alert based on key fields in the CAP 
alert sent by the alert initiator. Based on CMS provider profiles 
maintained in the Alert Gateway, the Alert Gateway would then deliver 
the alert over a secure interface operated by the CMS provider to 
another gateway maintained by the appropriate CMS provider (CMS 
Provider Gateway). Each individual CMS Provider Gateway would be 
responsible for the management of the particular CMS provider elections 
to deliver alerts. The CMS Provider Gateway would also be responsible 
for formulating the alert in a manner consistent with the individual 
CMS provider's available delivery technologies, mapping the alert to 
the associated set of cell sites/paging transceivers, and handling 
congestion within the CMS provider infrastructure. Ultimately, the 
alert would be received on a customer's mobile device. The major 
functions of the mobile device would be to authenticate interactions 
with the CMS provider infrastructure, to monitor for CMAS alerts, to 
maintain customer options (such as the subscriber's opt-out 
selections), and to activate the associated visual, audio, and 
mechanical (e.g., vibration) indicators that the subscriber has 
indicated as options when an alert is received on the mobile device. As 
part of its recommended model, the CMSAAC also proposed technical 
standards defining the functions of the Alert Aggregator, Alert 
Gateway, CMS Provider Gateway, CMS infrastructure, CMS handsets and 
various interfaces (i.e., A, B, C, D and E interfaces).
    11. In the CMAS NPRM, the Commission sought comment on the CMSAAC's 
proposed reference architecture, including its standards for defining 
the various element functions. Although most commenters supported the 
CMSAAC's proposal, a few objected to the CMSAAC's recommendation 
concerning the government-administered Alert Aggregator and an Alert 
Gateway. The Association of Public Television Stations (APTS) suggested 
that the Commission's role under the WARN Act is limited to adopting 
protocols to enable mobile services to opt into the Digital Emergency 
Alert System (DEAS). CellCast asserted that a national Aggregator/
Gateway is not required for CMAS implementation and that there are 
multiple models for alert distribution that do not use such an element. 
DataFM and the National Association of Broadcasters (NAB) raised 
concerns that a national aggregator would create a single point of 
failure that would reduce CMAS resiliency and/or introduce unacceptable 
performance degradation.
    12. According to the CMSAAC, a key element to CMS providers' 
ability to participate in the CMAS is the assumption of the Alert 
Aggregator and Alert Gateway functions by a Designated Federal 
Government Entity. Specifically, the CMSAAC recommended that the CMAS 
channel all Commercial Mobile Alert Messages (CMAMs) submitted by 
Federal, State, Tribal and local originators through a secure, Federal 
government administered, CAP-based alerting framework that would 
aggregate and hand off authenticated CMAMs to CMS Provider Gateways. 
The Commission sought comment on this recommendation in the CMAS NPRM. 
The overwhelming majority of commenting parties supported the CMSAAC's 
recommendation. Most wireless carriers commenting on the issue stressed 
that this was essential to CMS providers' participation in the CMAS. 
ALLTEL, for example, stated that if ``a federal government entity does 
not assume these roles, wireless service providers are less likely to 
participate'' in the CMAS because ``in an emergency situation it is 
imperative that wireless service providers are able to rely on a single 
source * * * and government officials are more appropriately trained in 
authenticating and constructing messages.''
    13. The Commission adopted the CMSAAC's proposed architecture for 
the CMAS. It found that the recommended model will facilitate an 
effective and efficient means to transmit alerts and find that the 
public interest will be served as such. Contrary to APTS's assertions, 
nothing in section 602(a) of the WARN Act mandates that the Commission 
only adopt requirements for CMS providers to opt into DEAS. While the 
Commission agreed with CellCast that there are other potential models 
for alert delivery by electing CMS providers, it noted that

[[Page 43103]]

none of those alternative solutions received the support of the CMSAAC. 
Moreover, the Commission noted that the CMSAAC recommendation is the 
result of consensus among commercial wireless carriers and their 
vendors, public safety agencies, organizations representing broadcast 
stations and organizations representing people with disabilities and 
the elderly, and other emergency alert experts. This consensus was 
reached after approximately ten months of deliberation. No other party 
has suggested an alternative that would be superior in meeting the 
needs of the commercial wireless industry and in ensuring that alerts 
are received by electing CMS providers and then are transmitted to 
their subscribers. In fact, both during the CMSAAC deliberations as 
well as throughout this proceeding, many wireless carriers have 
indicated that the inclusion of an alert aggregator and alert gateway 
function is essential to their participation in the voluntary CMAS.
    14. Finally, The Commission disagreed with the concerns raised by 
DataFM and NAB that a national aggregator would necessarily create a 
single point of failure. While the CMSAAC recommended a single logical 
aggregator/gateway function, the Commission expected that these 
functions will be implemented in a reliable and redundant fashion to 
maximize resiliency. Furthermore, given the volume of alerts expected 
for the CMAS, the Commission believes that technology for processing 
alerts will not place a constraint on aggregator/gateway performance. 
Accordingly, the Commission adopted the architecture proposed by the 
CMSAAC. As described below, however, the Commission adopted as rules 
only those CMAS elements within the control of the CMS providers.
    15. Federal Government Role. The Commission agreed with the CMSAAC 
and the majority of commenters that a Federally administered 
aggregator/gateway is a necessary element of a functioning CMAS. While 
no Federal agency has yet been identified to assume these two 
functions, the Commission believes that a Federal government 
aggregator/gateway would offer the CMS providers the best possibility 
for the secure, accurate and manageable source of CMAS alerts that the 
WARN Act contemplates.
    16. The Commission believes that FEMA, some other entity within 
DHS, or NOAA may be in the best position to perform these functions. 
DHS, and more specifically FEMA, traditionally has been responsible for 
origination of Presidential alerts and administration of the EAS. 
Moreover, Executive Order 13407 gives DHS primary responsibility for 
implementing the United States' policy ``to have an effective, 
reliable, integrated, flexible and comprehensive system to alert and 
warn the American people in situations of war, terrorist attack, 
natural disaster or other hazards to public safety and well-being.'' By 
the same token, the Department of Commerce, and more specifically NOAA 
Weather Radio, as the ``All Hazards'' radio network, acts as the source 
for weather and emergency information, including natural (such as 
earthquakes or avalanches), environmental (such as chemical releases or 
oil spills), and public safety (such as AMBER alerts or 911) warning 
information.
    17. FEMA also played an integral role in the development of the 
CMSAAC's recommendations. FEMA chaired the Alert Interface Group (AIG), 
which was responsible for addressing issues at the front-end of the 
CMAS architecture (e.g., receipt and aggregation of alerts, development 
of trust model to authenticate alerts from various sources). It also 
represented the AIG before the CMSAAC Project Management Group (PMG), 
which coordinated the work of all the other CMSAAC working groups and 
assembled the CMSAAC recommendations document. In addition, FEMA voted 
to adopt the CMSAAC recommendations in October 2007, which included 
CMAS reliance on a single Federal authority to fulfill the gateway/
aggregator role.
    18. The Commission recognizes that FEMA asserted in its February 
2008 comments that limits on its statutory authority preclude the 
agency from fulfilling the Federal aggregator/gateway functions. 
Nevertheless, timely identification of a federal agency capable of 
fulfilling the aggregator/gateway functions recommended by the CMSAAC 
is essential to bringing the concrete public safety benefits of a CMAS 
system to the American people. The Commission noted that it was hopeful 
that any bars that prevent FEMA or some other entity within DHS from 
fulfilling these roles will be lifted expeditiously. The Commission 
stated its intent to work with its Federal partners and Congress, if 
necessary, to identify an appropriate government entity to fulfill 
these roles, whether that is FEMA, another DHS entity, NOAA or the FCC.
    19. Scope of Order. Accordingly for purposes of this Order, the 
Commission proceeded on the assumption that a Federal agency will 
assume these roles at a future date. The Order is limited to adopting 
rules governing those sections of the CMAS architecture that are within 
the control of electing CMS providers. These include rules regarding 
the CMS Provider Gateway, CMS provider infrastructure, and CMS provider 
handsets. Specifically, the Commission adopted rules, based on the 
CMSAAC's recommendations, that require each individual CMS Provider 
Gateway to be able to receive alerts from the Federal government alert 
gateway over a secure interface (i.e., ``C Interface''). The CMS 
Provider Gateway will be required to, among other things: (1) Manage 
the CMS provider's election to provide alerts; (2) format alerts 
received in a manner consistent with the CMS provider's available 
delivery technology; (3) map alerts to the associated set of cell 
sites/paging transceivers; and (4) manage congestion within the CMS 
provider's infrastructure. In addition, The Commission adopted rules, 
based on the CMSAAC's recommendations, requiring the CMS infrastructure 
to, among other things: (1) Authenticate interactions with the mobile 
device; (2) distribute received CMAS alert messages to the appropriate 
set of cell sites/paging transceivers for transmission to the mobile 
device; and (3) transmit the CMAS alert message for each specified cell 
site/pager transceiver.
    20. The Commission adopted the CMSAAC's recommendations regarding 
capabilities of the mobile device including that it: (1) Authenticate 
interactions with the CMS provider infrastructure; (2) maintain 
configuration of CMAS alert options; and (3) present received CMAS 
alert content to the subscriber. In addition, as explained below, the 
Commission adopted requirements for the mobile device to ensure that 
people with disabilities are able to receive CMAS alerts. The 
Commission also adopted the CMSAAC's recommendation that CMAS alerts 
not preempt ongoing voice or data sessions.
    21. In keeping with the Commission's policy to promote 
technological neutrality, it declined to adopt rules governing the 
communications protocols that the CMS providers must employ for 
communications across the D or E interfaces as identified in the 
architecture. The Commission agreed with the CMSAAC that no specific 
protocols should be required for the D and E interface, but rather that 
CMS providers should be allowed to retain the discretion to define 
these protocols in conjunction with their overall network design and 
with the mobile device vendors. Both of these interfaces lie entirely 
within the control of the

[[Page 43104]]

CMS providers and any implementation decisions there will have no 
impact on CMAS ability to satisfy the system requirements the 
Commission sets forth elsewhere in this Order. For example, while the 
Commission includes requirements on the type of alert information that 
must cross the D and E interfaces to enable CMAS alerts on mobile 
devices, it chose to remain silent as to the precise communications 
protocol that a CMS provider uses to convey this information to the 
mobile device. This approach gives the CMS providers maximum 
flexibility to leverage technological innovation and implement the CMAS 
in a cost effective manner.
    22. The Commission also adopted rules requiring, per the CMSAAC's 
recommendation, that electing CMS providers assemble individual profile 
information to provide to the Authorized Federal Government Entity, 
once that entity is identified. The Commission believes that electing 
CMS providers expect to assemble this information, and by adopting this 
requirement now, it is providing direction to potential Alert Gateway 
providers.
    23. The CMSAAC recommended detailed technical protocols and 
specifications for the Alert Aggregator/Gateway entity and the CMS 
providers to employ for the delivery of alerts over the various 
interfaces (i.e., A, B and C interfaces) in the Reference Model. 
Specifically, section 10 of the CMSAAC recommendations proposed 
requirements that Alert Initiators must meet to deliver CMAS alerts to 
the Alert Aggregator, and that the Alert Gateway must meet to deliver 
CMAS alerts to the CMS Provider Gateway. The CMSAAC also recommended 
CAP-based mapping parameters.
    24. The Commission supports the technical protocols and 
specifications for the delivery of alerts recommended by the CMSAAC in 
this section. Electing CMS providers could use these technical 
protocols and specifications to design their internal systems that 
would enable compliance with the rules the Commission adopts in this 
docket. The Commission declines, however, to codify these protocols and 
specifications in this Order. It believes that these protocols offer a 
significant guidance to CMAS participants as they further develop the 
final protocols and interface for the CMAS, but until an Alert 
Aggregator/Gateway entity is determined, additional refinements and 
revisions of these protocols and specifications are inevitable. 
Accordingly, the Commission concludes that final determination of these 
interface protocols is better left to industry standards organizations. 
The Commission noted that it will revisit this matter in the future if 
Commission action in this area is indicated.

General CMAS Requirements

    25. In this section, the Commission establishes the basic 
regulatory framework of the new CMAS. Specifically, it adopts 
technologically neutral rules that address, among other things, the 
scope of CMAS alerts, geo-targeting and alert accessibility for people 
with disabilities and the elderly.
    26. Scope and Definition of CMAS Alerts. The WARN Act requires the 
Commission to enable commercial mobile alerting capabilities for 
``emergency'' alerts, but does not define what may comprise an 
emergency. Accordingly, in the CMAS NPRM, the Commission sought comment 
on the appropriate scope of emergency alerts, including whether and to 
what extent alerts should be classified. The Commission specifically 
asked parties to address whether it should implement the CMSAAC's 
recommendation to specify three alert classes: (1) Presidential Alert; 
(2) Imminent Threat Alert; and (3) Child Abduction Emergency or AMBER 
Alert. For the reasons stated below, the Commission finds that the 
public interest will be best served by its adopting these three alert 
classes, which it defines below.
    27. The Commission agrees with the majority of commenters that the 
three classes of alert recommended by the CMSAAC achieves the best 
balance between warning of imminent threat to life and property with 
the current technical limits that CMS provider systems face in 
delivering timely, accurate alerts. Alert Systems however argues that 
the Commission should include additional classes of alerts, such as 
traffic advisories. The Commission finds that inclusion of such alerts 
would be inconsistent with the intent of Congress, expressed throughout 
the WARN Act, that the Commission enable an ``emergency'' alerting 
system. The Commission believes that if the public were to receive 
commercial mobile alerts that do not relate to bona fide emergencies, 
there would be a serious risk that the public would disregard mobile 
alerts or possibly opt not to receive anything but Presidential alerts. 
The Commission also notes that, given the current technical 
capabilities of CMS providers to deliver emergency alerts, it is 
possible that if too many alerts are injected into a CMS provider's 
system in a very brief period, vital messages could be delayed. Accord- 
ingly, the Commission rejects arguments to broadly define eligible 
alert classes beyond those specified here.
    28. Presidential Alerts. Section 602(b)(2)(E) of the WARN Act 
authorizes participating CMS providers to allow device users to prevent 
the receipt of alerts or classes of alerts ``other than an alert issued 
by the President.'' Congress thus intended to afford Presidential 
Alerts the highest priority. Affording Presidential Alerts the highest 
priority also will enable the Secretary of Homeland Security to meet 
his/her obligation, under Executive Order 13407, to ``ensure that under 
all conditions the President of the United States can alert and warn 
the American people.'' Accordingly, electing CMS providers must 
transmit such alerts and assign the highest priority to any alert 
issued by the President or the President's authorized designee. 
Further, Presidential Alerts must be transmitted upon receipt by a CMS 
provider, without any delay, and therefore will preempt any other 
pending alert. The Commission notes that due to the initial 90-
character text message protocol that it is adopting below for the first 
generation CMAS, it is possible that a Presidential Alert may direct 
recipients to other sources, possibly taking the form recommended by 
the CMSAAC: ``The President has issued an Emergency Alert. Check local 
media for more details.''
    29. Imminent Threat Alerts. The Commission notes that virtually all 
commenting parties support adoption of the CMSAAC's recommendation to 
define an Imminent Threat Alert class. This alert class is narrowly 
tailored to those emergencies where life or property is at risk, the 
event is likely to occur, and some responsive action should be taken. 
Specifically, an Imminent Threat Alert must meet separate thresholds 
regarding urgency, severity, and certainty. Each threshold has two 
permissible CAP values.
     Urgency. The CAP ``urgency'' element must be either 
Immediate (i.e., responsive action should be taken immediately) or 
Expected (i.e., responsive action should be taken soon, within the next 
hour).
     Severity. The CAP ``severity'' element must be either 
Extreme (i.e., an extraordinary threat to life or property) or Severe 
(i.e., a significant threat to life or property).
     Certainty. The CAP ``certainty'' element must be either 
Observed (i.e., determined to have occurred or to be ongoing) or Likely 
(i.e., has a probability of greater than fifty percent). That is, the 
event must have occurred, or be occurring (Observed), or be more likely 
to occur than not (Likely).

[[Page 43105]]

    30. The Commission finds that the transmission of these imminent 
threat alerts is essential to a useful CMAS. The CMSAAC recommended 
such action and the commenting parties overwhelmingly support this 
conclusion. As T-Mobile correctly states, CMAS alerts are not 
appropriate for warning the public about minor events. Subscribers are 
more likely to opt out if they are bombarded by minor notices, and may 
fail to notice a truly serious alert. Also, inclusion of minor events 
would be an unnecessary burden on the CMS provider infrastructure. 
Accordingly, the Commission finds it appropriate to require 
participating CMS providers to transmit Imminent Threat Alerts.
    31. Child Abduction Emergency/AMBER Alerts. There is broad support 
in the record for adoption of the CMSAAC's recommendation to specify a 
third alert class, Child Abduction Emergency or AMBER Alert. There are 
four types of AMBER Alerts: (1) Family Abduction, (2) Nonfamily 
Abduction, (3) Lost, Injured, or Otherwise Missing, and Endangered 
Runaway. AMBER plans are voluntary partnerships between law enforcement 
agencies, broadcasters and CMS providers to activate an urgent bulletin 
in the most serious child abduction cases, and AMBER alerts are issued 
only where an AMBER plan has been duly established. The Commission also 
notes that a number of CMS providers currently transmit AMBER Alerts 
using Short Message Service (SMS) technology, and applauds their 
potentially life-saving efforts in this regard.
    32. In 2006, 261 AMBER Alerts were issued in the United States 
involving 316 children. Most of these alerts were issued on an 
intrastate basis. Of the 261 AMBER Alerts issued in 2006, 214 cases 
resulted in a recovery, 53 of which were resolved as a direct result of 
an AMBER Alert being issued. Based on the limited number of AMBER 
alerts and their confined geographic scope, the Commission does not 
expect such alerts to be overly burdensome to CMS providers that 
participate in the CMAS. Moreover, because of the efficacy of AMBER 
Alerts, the Commission finds that the public interest in the safety of 
America's children will be well served by the provision of AMBER Alerts 
by the wireless industry. Accordingly, the Commission requires 
participating CMS providers to transmit AMBER alerts.
    33. Technologically Neutral Alert System. The CMSAAC recommended 
that CMS providers that elect to participate in the CMAS should ``not 
be bound to use any specific vendor, technology, software, 
implementation, client, device, or third party agent, in order to meet 
[their] obligations under the WARN Act.'' The Commission agrees. As 
SouthernLINC notes, participating CMS providers should be able to 
choose the technology that will allow them to best meet the emergency 
alerting needs of the American public. Consistent with the Commission's 
well-established policy of technologically-neutral regulation of the 
wireless telecommunications industry, it believes that CMS providers 
and equipment manufacturers are in the best position to select and 
incorporate the technologies that will enable them to most effectively 
and efficiently deliver mobile alerts. Accordingly, the Commission does 
not limit the range of technologies that electing CMS providers may 
deploy to participate in the CMAS. In reaching this conclusion, the 
Commission balances the alerting needs of the public and the 
capabilities of electing CMS providers and the Commission's mandate 
under section 602(a) of the WARN Act to enable the provision of 
emergency alerts. The Commission emphasizes that the WARN Act does not 
require the establishment of any specific technology to be used for the 
CMAS.
    34. CMS providers are in various stages of readiness to participate 
in the CMAS. Paging carriers already provide point to multipoint 
services, using technologies such as ReFLEX and POCSAG (Post Office 
Code Standardization Advisory Group), to reach many subscribers at the 
same time and therefore appear well-positioned to participate in CMAS. 
However, as the American Association of Paging Carriers notes, it may 
not be feasible for paging carriers to confine their alerts to either 
county-wide or sub-county distribution. Further, cellular, PCS, and SMR 
service providers, report that they have not deployed an emergency 
alerting capability that satisfies all requirements in the CMSAAC 
recommendations and that is currently available for the mass 
transmission of alerts. The Commission notes that many of the 
requirements that it adopts are intended to apply to a first generation 
text-based alerting service. Other service profiles, such as streaming 
audio and video, are in their early developmental stages and thus not 
ripe for implementation by the Commission. The Commission foresees that 
as CMS providers gain experience with these and other alerting 
technologies, they may well be incorporated into future alerting system 
deployments.
    35. Although the CMSAAC found that point-to-point technologies may 
not be well suited for mass alerting, the Commission will not prohibit 
their use if a CMS provider can otherwise meet the requirements that 
the Commission establishes. Short Message Service (SMS) text messaging 
is available to most cellular, PCS, and SMR subscribers and is 
currently used by some municipalities and other local jurisdictions to 
provide emergency alerts on an opt-in basis. The Commission recognizes, 
however, that SMS may not be a desirable solution for the widespread 
dissemination of alerts to the public because the mass delivery of SMS-
formatted alerts could degrade network performance and delay alert 
delivery. Despite these potential drawbacks, SMS text messaging may 
offer a viable, short-term delivery method for electing CMS providers 
that do not yet have a point-to-multipoint text messaging capability.
    36. The CMSAAC noted that technologies such as MediaFLO and DVB-H 
``may provide supplemental alert information,'' but recommended that 
they should not be considered as part of the CMAS. The Commission's 
goal in this proceeding is to enable the broadest possible voluntary 
participation in the CMAS, and it will not foreclose the possible 
deployment of these or other innovative technologies as a means of 
participating in the nascent CMAS. The public interest is best served 
by not circumscribing the range of technologies that CMS providers may 
elect to deploy to meet the alerting needs of the American public.
    37. Several parties express support for an FM-based CMAS solution 
such as that provided by ALERT-FM and Global Security Systems. The 
CMSAAC however considered the costs and benefits of Radio Broadcast 
Data System (RBDS) and other FM-based alert and warning solutions, and 
found them to be infeasible for the CMAS. Moreover, a number of parties 
have expressed reservations about these technologies. Nonetheless, in 
keeping with its overall policy to maintain technological neutrality, 
the Commission does not require or prohibit the use of ALERT-FM, RBDS 
or similar systems as the basis of the CMAS.
    38. The Commission also strongly encourages fair, reasonable, and 
nondiscriminatory Intellectual Property Rights (IPR) licensing in the 
context of the CMAS. It agrees with the CMSAAC that the technical 
standards, protocols, procedures, and related requirements that the 
Commission adopts pursuant to section 602(a) of the WARN Act should be 
standardized in industry bodies that have well defined IPR policies. 
The Commission declines, however, to compel all CMSAAC participants 
``to

[[Page 43106]]

provide written assurance to the Commission that, if and insofar as one 
or more licenses may be required under any of their respective IPRs 
that are technically essential for purposes of implementing or 
deploying CMAS, the rights holders shall license such IPR on a fair, 
reasonable and nondiscriminatory basis for those limited purposes 
only.'' The Commission also declines to require ``all participants in 
the public comment process on th[e] CMAS Architecture and Requirements 
document'' to make such a written assurance. These requests are outside 
the scope of section 602(a) of the WARN Act.
    39. The CMSAAC made a number of additional recommendations that the 
Commission concludes are outside the scope of its mandate under section 
602(a) of the WARN Act to adopt ``technical standards, protocols, 
procedures, and other technical requirements,'' to enable voluntary 
commercial mobile alerting. Specifically, the CMSAAC submitted 
recommendations regarding the applicability of requirements for 
location, number portability and the Communications Assistance for Law 
Enforcement Act (CALEA). The CMSAAC also submitted recommendations on 
whether CMS providers may utilize the technical requirements adopted 
herein for other services and purposes and whether CMS providers may 
recover certain costs related to the development of the CMAS. The 
Commission finds that these issues are outside the scope of section 
602(a) of the WARN Act and, therefore, does not address these issues in 
the Order.
    40. The CMSAAC recommended that, to the extent practicable, 
``Federal, state, tribal, and local level CMAS alert messages [should] 
be supported using the same CMAS solution.'' The Commission agrees and 
believes that a uniform approach to implementation of the CMAS will be 
inherently more cost effective, more technologically consistent and 
thus more likely to facilitate participation by small and rural CMS 
providers. Further, the Commission agrees that electing CMS providers 
should not be required to support alerting on mobile handsets 
manufactured for sale to the public prior to a CMS provider's 
initiation of the CMAS alerting service. In a subsequent order, the 
Commission will address how participating CMS providers may sell such 
non-compliant handsets consistent with the requirement under section 
602(b) of the WARN Act that they disclose ``at the point of sale of any 
devices with which its commercial mobile service is included, that it 
will not transmit such alerts via the service it provides for the 
device.'' Finally, the Commission agrees that electing CMS providers 
should have discretion regarding whether certain devices, such as 
laptop wireless data cards, will support alerting capabilities.

CMAS Message Elements and Capabilities

    41. Required Alert Message Elements. The CMSAAC recommended that 
emergency alert messages follow the same general format of National 
Weather Service alert messages, subject to a 90-character text 
limitation. Specifically, the CMSAAC recommended that for initial CMAS 
deployments, messages should include five elements in the following 
order:
     Event Type or Category
     Area Affected
     Recommended Action
     Expiration Time (with time zone)
     Sending Agency
    42. The CMSAAC proposed this format to facilitate CAP value field 
mapping to text. It also noted that the format would likely evolve as 
experience is gained by alert initiators and by electing CMS providers. 
In the CMAS NPRM, the Commission sought comment on the five elements 
and asked parties to address whether the elements are consistent with 
accepted industry practices for emergency alerts.
    43. There is broad support in the record for standardization of 
alert messages and adoption of the five recommended message elements. 
T-Mobile explains that the format ``is designed to ensure that the most 
critical information is succinctly and clearly communicated in a manner 
most compatible with the technical attributes of wireless networks.'' 
Purple Tree Technologies also supports the five message elements, but 
urges that event type and area affected be the only required elements, 
with others optional if space permits. Based on the Commission's review 
of the record, it finds that on balance the five message elements 
identified above will enable standardization of alerting messages and 
adopts them. The Commission rejects Alert Systems' claim that the 
element for ``area affected'' should be reconsidered based on its 
hypothesis that ``visitors and newcomers to areas often do not 
recognize geographic landmarks in warning messages.'' A biohazard or 
flash flood warning, for example, would not enable the public to avoid 
a lethal hazard without appropriate area affected information. The 
Commission also expects that as CMAS providers eventually deploy 
technologies capable of messages of more than 90 characters, additional 
alert message elements will be implemented.
    44. In the CMAS NPRM, the Commission also sought comment on whether 
alert messages should include telephone numbers, URLs or other response 
and contact information, including any related network impacts. The 
CMSAAC advised against inclusion of URLs or telephone numbers because 
such information would encourage mass access of wireless networks. The 
California Public Utility Commission (CAPUC) supports inclusion of a 
sixth message element for URLs, if feasible. AT&T (and many commenting 
parties) note that inclusion of a URL or telephone number in an 
emergency message, some of which might be delivered to tens of 
thousands of users in a matter of seconds, could lead to unacceptable 
network congestion and, in extreme cases, network failure. The 
Commission finds that mandating URLs or telephone numbers in an 
emergency alert could exacerbate wireless network congestion at a time 
when network traffic is already dramatically increasing as individuals 
contact police, fire, and rescue personnel, as well as their loved 
ones. The Commission therefore will not require participating CMS 
providers to accept or transmit any alert message that contains an 
embedded URL or telephone number.
    45. CMAS Generation of Free Text Alert Messages. In the CMAS NPRM, 
the Commission sought comment on the CMSAAC's recommendation that the 
Alert Gateway automatically generate messages by extracting information 
from specified fields of a CAP-formatted message, SAME codes, or free-
form text, which would then be transmitted across Reference Point C to 
electing CMS providers. The CMSAAC recommended this approach for 
initial system deployments. The Commission also sought comment on the 
CMSAAC's recommendation to allow the generation of free text for 
Presidential and AMBER alert messages. While numerous parties in this 
proceeding support adoption of the CMSAAC recommendations in full, few 
address the specific mechanics of generating alert messages via the 
Alert Gateway. AT&T states that proposals for automatic generation of 
alert text ``merit further investigation, but responsibility for the 
content of alerts should remain with initiators and the federal 
government--not wireless carriers.'' The Commission agrees with AT&T 
and other parties that electing CMS providers should act as a conduit 
for messages, the content of which is fixed before transmission to a 
CMS provider.

[[Page 43107]]

    46. CellCast argues that the Commission should ``ignore'' the 
CMSAAC recommendations regarding alert generation, asserting that 
message generation is beyond its mandate under the WARN Act. The 
mechanisms for generating messages at the Alert Gateway are undefined 
currently and may be subject to implementation by the federal entity 
selected to administer the Alert Gateway. Nonetheless, the Commission 
supports the CMSAAC's recommended approach of allowing the Alert 
Gateway to create messages using CAP fields and SAME codes. 
Specifically, the Commission believes that this approach would enable 
the provision of consistent and accurate messages to the public, while 
facilitating future enhancements to the Alert Gateway.
    47. The Commission also agrees with the CMSAAC that automatic 
generation of messages via CAP fields and SAME codes may not always 
provide sufficient flexibility to alert initiators to tailor messages 
for emergencies that may fall with the Imminent Threat Alert category. 
A message with a translated event code of ``security warning,'' for 
example, may not provide adequate information about a shooting incident 
on a college campus. A more apt warning might be ``a shooting has 
occurred on the north campus,'' with directions to ``stay indoors.'' 
The Commission thus believes that the public interest would be served 
if the CMAS architecture accommodates free-form text messaging, subject 
to the 90-character text limit that it adopts and its determination 
that electing CMS providers will generally not be obligated to accept 
or transmit any alert message that includes an embedded URL or phone 
number. The Commission also agrees with the CMSAAC that free-form text 
should be included as a CAP message parameter.
    48. Finally, the Commission concurs with the CMSAAC that automatic 
text generation at the Alert Gateway would be impractical for 
Presidential or AMBER Alerts, both of which are likely to be highly 
fact specific. As the CMSAAC noted, the efficacy of a particular AMBER 
Alert hinges on specific information such as a description of a 
vehicle, abductor, or missing child. Accordingly, the Commission finds 
that law enforcement authorities should have the ability to formulate 
unique message text for the dissemination of AMBER Alerts via the CMAS. 
The Commission envisions that such free text messages would be 
presented to the Alert Gateway in a free text CAP field. In the event 
of a Presidential Alert, it agrees with the CMSSAC that, until such 
time as electing CMS providers are able to transmit messages longer 
than 90 characters, the Alert Gateway may employ a generic statement 
such as ``The President has issued an emergency alert. Check local 
media for more details.''
    49. Geo-targeting CMAS Alerts. The CMSAAC recommended that ``to 
expedite initial deployments of CMAS an alert that is specified by a 
geocode, circle or polygon'' should ``be transmitted to an area not 
larger than the CMS [provider's] approximation of coverage for the 
county or counties with which that geocode, circle, or polygon 
intersects.'' The Commission, based on the substantial record before 
it, and for the reasons stated below, requires electing CMS providers 
to geographically target (geo-target) alerts accordingly. The 
Commission notes that radio frequency (RF) propagation areas for some 
paging systems and cell sites may exceed a single county, and will 
permit geo-targeting that exceeds county boundaries in these limited 
circumstances.
    50. Congress recognized the importance of geo-targeting alerts in 
the WARN Act. Specifically, in section 604 of the WARN Act, Congress 
directed the Under Secretary of Homeland Security for Science and 
Technology, in consultation with the National Institute of Standards 
and Technology (NIST) and the FCC, to establish a research program for 
``developing innovative technologies that will transmit geographically 
targeted emergency alerts to the public.'' The Commission stands ready 
to work with DHS and NIST to facilitate this important undertaking. The 
Commission fully expects that as more refined and cost effective geo-
targeting capabilities become available to electing CMS providers, they 
will voluntarily elect to target alerts more granularly. Several CMS 
providers have indicated their intention to geo-target alerts below the 
county level and the Commission strongly encourages them to do so. As 
T-Mobile notes, electing CMS providers should be free to target more 
specifically, subject to the liability protections of the WARN Act.
    51. In the CMAS NPRM, the Commission sought comment on what level 
of precision it should require for geo-targeting, considering the 
CMSAAC's recommendation for county-level geo-targeting. The CMSAAC 
recognized ``that it is the goal of the CMAS for CMS providers to be 
able to deliver geo-targeted alerts to the areas specified by the Alert 
Initiator.'' Based upon current capabilities and to expedite initial 
deployments, the CMSAAC recommended targeting ``an area not larger than 
the CMS [provider's] approximation of coverage for the county or 
counties with which [a transmitted] geocode, circle, or polygon 
intersects.'' The CMSAAC recommended that providers should be allowed 
(but not required) to deliver alerts to areas smaller than a county, 
using Geographic Names Identification System (GNIS) codes, polygon, or 
circle information to identify a predefined list of cell sites/paging 
transceivers within the alert area.
    52. Several parties however urge us to mandate sub-county 
targeting. Alert Systems claims that disaster managers often require 
greater geographic granularity than that permitted by CAP and the 
CMSAAC recommendations. Purple Tree Technologies asserts that sub-
county targeting is ``possible with cell broadcast,'' and that there 
are few technical hurdles preventing granular alerts. Acision and 
CellCast both contend that cell broadcast technology would allow for 
targeting to the individual cell level. DataFM claims its technology 
could target ``specific geographic areas without regard to the location 
of its transmitters.''
    53. The National Emergency Number Association (NENA) favors 
targeting smaller areas, noting that some counties are very large and 
that alert originators often need to target precisely. NENA asserts 
that targeting messages to the block level (similar to emergency 
telephone notification systems) would be ``ideal,'' but recognizes this 
is not possible. The CAPUC argues that county targeting would be 
overbroad for most emergencies, and urges ZIP-code level targeting. The 
Commission notes that there are more than 40,000 active ZIP codes in 
the United States, and many of these are assigned to specific 
addresses. The CAPUC does not explain how ZIP code targeting could be 
implemented.
    54. The weight of the record supports county-level targeting as 
recommended by the CMSAAC. CTIA, TIA and 3G Americas urge us to 
implement county-level targeting, with optional granularity, to 
encourage expeditious deployment of alerting capabilities. T-Mobile 
agrees that electing CMS providers should not be required to target 
alerts to areas smaller than a county, noting that given current 
technological limitations, many carriers would be unable to achieve 
more specificity. Alltel also supports county-level targeting, but 
states that it intends to target more granularly.
    55. MetroPCS notes that for smaller targeting areas, electing CMS 
providers would have to more precisely control the delivery of messages 
by the base

[[Page 43108]]

stations serving a given targeted area than is currently economically 
feasible. Similarly, The National Telecommunications Cooperative 
Association (NTCA) states that requiring electing rural CMS providers 
to send alerts to sub-county areas may be too expensive and may reduce 
the incentive to participate in the CMAS. The American Association of 
Paging Carriers (AAPC) opposes county-level targeting, noting that it 
may not be feasible for some paging providers to confine alerts to the 
county level, and that they would target alerts to the extent permitted 
by their networks.
    56. Based on the foregoing, and subject to the limited exception 
discussed below, the Commission concludes that it would be premature 
for it generally to require targeting of alerts more precisely than the 
county level. The Commission specifically notes that county-level 
targeting is consistent with the current practices of the National 
Weather Service, which is expected to originate many CMAS alerts. While 
some commenters argue that cell broadcast and perhaps other 
technologies could support more granular targeting, the record 
indicates that not all CMS providers may employ cell broadcasting for 
their delivery of CMAS. Further, while several vendors urge us to 
mandate sub-county targeting, at this point the Commission finds that 
the public interest is best served by enabling participating CMS 
providers to determine which technologies will most efficiently and 
cost effectively allow them to target alerts more precisely than the 
county level.
    57. Accordingly, the Commission generally requires CMS providers 
that elect to participate in the CMAS to geographically target 
emergency alerts to the county level. In adopting this rule, the 
Commission recognizes the concerns of many CMS providers that face 
technical limitations on their ability to geo-target alerts to areas 
smaller than a county. In those limited circumstances where the 
propagation area of a paging system or cell site exceeds a single 
county, the Commission will permit the RF signal carrying the alert to 
extend beyond a county's boundaries. Electing CMS providers may 
determine which network facilities, elements, and locations will be 
used to transmit alerts to mobile devices. Regarding the CMSAAC 
recommendation that, until such time as emergency alerts can be 
delivered to areas smaller than a county in real-time (i.e., dynamic 
geo-targeting), certain urban areas with populations of greater than 1 
million or with specialized alerting needs be identified for more 
precise geo-targeting, the Commission will address this recommendation 
once an entity has been identified to provide the Alert Aggregator and 
Gateway functions.
    58. Meeting the Needs of Users, Including Individuals with 
Disabilities and the Elderly. Section 603(b)(3)(F) of the WARN Act 
required that the CMSAAC include representatives of national 
organizations representing people with special needs, including 
individuals with disabilities and the elderly. Because the WARN Act 
directed the CMSAAC to submit recommendations to the Commission ``as 
otherwise necessary to enable electing CMS providers to transmit 
emergency alerts to subscribers,'' the CMSAAC concluded, and the 
Commission agrees, that Congress intended to include the elderly and 
those with disabilities among the class to which electing CMS providers 
are to deliver alerts. Accordingly, the Commission concludes that CMAS 
access to those with disabilities and the elderly falls within its 
obligation under section 602(a) of the WARN Act, and thus seek to 
ensure that commercial mobile alerts are accessible to all Americans, 
including individuals with disabilities and the elderly.
    59. The CMSAAC recommended that the needs of individuals with 
disabilities and the elderly be addressed by, inter alia, the inclusion 
of a common audio attention signal, and a common vibration cadence, on 
devices to be used for commercial mobile alerts. The CMSAAC recommended 
that both functions be distinct from any other device alerts and 
restricted to use for commercial mobile alerting purposes. The CMSAAC 
further noted that these features would benefit not only individuals 
with disabilities and the elderly, but also subscribers more generally.
    60. For devices with polyphonic capabilities, the CMSAAC 
recommended that the audio attention signal should consist of more than 
one tone, in a frequency range below 2 kHz and preferably below 1 kHz, 
combined with an on-off pattern to make it easier for individuals with 
hearing loss to detect. For devices with only a single frequency 
capability, the CMSAAC recommended an audio attention signal below 2 
kHz. The CMSAAC also recommended that the unique vibration cadence 
should be noticeably different from the default cadence of the handset. 
The CMSAAC further recommended that if a device includes both the audio 
and vibration functions, simultaneous activation of both functions 
should not be required and that configuration should be determined by 
end users.
    61. In the CMAS NPRM, the Commission sought comment on the CMSAAC 
recommendations, including any technical or accessibility requirements 
that the Commission should adopt to ensure that commercial mobile 
alerts will be received by individuals with disabilities and the 
elderly. The Commission asked whether attention signals should be 
required for all users. It also noted that the CMSAAC recommended that 
alert initiators use clear and simple language whenever possible, with 
a minimal use of abbreviations and the ability to recall alert messages 
for review--and sought comment on these recommendations within the 
context of accessibility for individuals with disabilities and the 
elderly.
    62. Nearly all commenting parties support the CMSAAC's 
recommendations for addressing the needs for individuals with 
disabilities and the elderly. AT&T, for example, states that adoption 
of the CMSAAC's recommendations for a common audio signal and vibration 
cadence will ``allow for the immediate identification of emergency 
alerts'' and foster ``the widest possible distribution of alerts'' to 
the public. Alert Systems likewise notes that ``[u]rgency coding of 
messages is vital,'' and that caretakers and operators of certain 
industrial facilities in particular ``need unique alert tone patterns/
amplitudes to quickly reprioritize activities.''
    63. The Wireless Rehabilitation Engineering Research Center for 
Wireless Technologies (Wireless RERC) supports adoption of a common 
audio attention signal, and recommends that the Commission adopt the 
existing 8-second EAS attention signal for all users, asserting that it 
provides the necessary period of time to alert individuals with hearing 
disabilities. The Wireless RERC also supports adoption of a common 
vibration cadence, and states that electing CMS providers should 
provide clear instructions on the alert capabilities of their devices, 
including labels identifying mobile devices suitable for persons with 
audio and visual disabilities. AAPC supports the CMSAAC 
recommendations, but states that legacy devices should not be required 
to support such functions. CAPUC adds that although the CMSAAC was 
required to issue recommendations on wireless alerts exclusively, the 
Commission should consider ensuring interoperability with wireline 
devices for individuals with disabilities and the elderly, noting that

[[Page 43109]]

some such users may not have access to wireless devices. DataFM notes 
that it currently has equipment for text-to-speech for the blind and 
strobe light warnings for the deaf, and would employ audio alerts and 
vibration alerts for portable devices.
    64. Although there is near unanimous support of the CMSAAC's 
recommendations for addressing the needs of individuals with 
disabilities and the elderly, several parties argue that no additional 
requirements are necessary. MetroPCS claims that the handsets that will 
be used to receive mobile alerts are already subject to disability 
access requirements, and any additional requirements may raise costs, 
thereby discouraging CMS provider participation. CellCast argues that 
no changes to CMS provider networks should be required, noting that 
some mobile devices can be configured to enable the elderly or blind to 
hear an audio conversion of the message using text-to-speech 
technologies.
    65. The Commission agrees with the majority of those commenting and 
the CMSAAC that it is vital that the Commission ensures access to 
commercial mobile alerts by individuals with disabilities and the 
elderly. The Commission disagrees with the premise articulated by some 
commenters that merely because some device manufacturers already 
include accessibility features for receipt of mobile alerts, no 
requirements are needed to ensure access to mobile alerts for 
individuals with disabilities and the elderly.
    66. Accordingly, to address the needs of these user groups and the 
needs of users more generally, the Commission will require that 
participating CMS providers include both a common vibration cadence and 
a common audio attention signal on any device offered to the public for 
reception of commercial mobile alerts. Specifically, as the CMSAAC 
recommended, the Commission specifies a temporal pattern for the audio 
attention signal of one long tone of two (2) seconds, followed by two 
short tones of one (1) second each, with a half (0.5) second interval 
between the tones. The Commission also requires that the entire 
sequence be repeated twice with a half (0.5) second interval between 
repetitions. For devices with polyphonic capabilities, the Commission 
adopts the CMSAAC's recommendation that the audio attention signal 
consist of the two EAS tones (853 Hz and 960 Hz). For devices with a 
monophonic capability, the Commission requires that a universal audio 
attention signal be of 960 Hz (the higher frequency EAS tone).
    67. The Commission also seeks to facilitate recognition of alerts 
for individuals that may have a hearing disability (or who may have 
muted the audio attention signal on their device), and therefore adopts 
the same temporal pattern for the vibration cadence as the CMSAAC 
recommended that the Commission specify for the audio attention signal. 
The Commission strongly encourages CMS providers to coordinate with 
device manufacturers to utilize existing technologies to comply with 
these requirements as soon as possible.
    68. The Commission recognizes that incorporating capabilities for a 
common audio attention signal and a common vibration cadence on the 
many devices that it expects to be offered to the public will take time 
to develop and implement successfully. However, the Commission believes 
that assuring full access for all Americans is sufficiently important 
that equipment may not be considered CMAS compliant unless it includes 
both the common audio attention signal and the vibration cadence 
adopted in this Report and Order. Further, both functions must be 
distinct from any other incoming message alerts and restricted to use 
for CMAS alerting purposes. Finally, simultaneous activation of both 
the audio attention signal and vibration cadence is permissible.
    69. Output Mode/Display. The CMSAAC issued several recommendations 
regarding the output mode/display of mobile devices. Specifically, the 
CMSAAC recommended that CMAS-enabled mobile devices should employ 
display fonts that are easily readable with recognizable characters, 
citing three typeface examples. MetroPCS notes that certain 
accessibility requirements already apply to CMS providers, and that 
CMAS-enabled mobile devices will therefore accommodate certain 
disabilities. CellCast adds that the development of mobile devices is 
highly competitive and flexible enough to meet the needs of all users 
including those with special needs. Although the Commission agrees with 
the CMSAAC that ``the goal in font selection is to use easily 
recognizable characters,'' it does not want to constrain the ability of 
CMS providers and manufacturers of devices to implement display modes 
that they find will best meet the needs of people with disabilities and 
other users. Accordingly, the Commission does not limit the display of 
CMAS alerts to a particular font or character set.
    70. Text-to-speech (TTS) enabled wireless mobile devices are 
becoming increasingly common, and the Commission strongly encourages 
all participating CMS providers to offer devices with such capabilities 
so that blind individuals and those with severe visual impairments can 
obtain the public safety benefits of commercial mobile alerts. The 
Commission notes that many of the requirements that it adopts for the 
first generation of CMAS are intended to enable the provision of text-
based alerts to the public. Although the Commission envisions that the 
CMAS will evolve to include audio and video service profiles, it finds 
that at this initial stage of the CMAS, it would be premature to 
address the CMSAAC's recommendations regarding output mode/displays for 
such future service profiles.
    71. Message Retransmission. The Commission agrees with the CMSAAC 
that alerts should be retransmitted periodically to an affected area 
until their specified expiration. Periodic retransmission of alerts is 
vital because some individuals, particularly motorists, may enter an 
alert area after initial transmission of an alert. Others may miss the 
initial alert because of an ongoing call (as explained below, alerts 
may not preempt a call in progress), or because they had their mobile 
device turned off or muted when an alert was first transmitted. As the 
CMSAAC noted, the optimal frequency of alert retransmission requires a 
balancing of many factors, including the capabilities of a CMS 
provider's delivery technology and end users' handsets, the number of 
ongoing active alerts, device battery life, and impacts on network call 
and data processing. The CMSAAC recommended that each CMS provider 
should determine how often an alert will be retransmitted based on such 
considerations. The Commission agrees with this assessment and adopts 
this recommendation as reasonable for the initial implementation of the 
CMAS. As the system is deployed, the Commission may wish to revisit the 
issue to see if a consistent, industry-wide alert retransmission 
interval would be more appropriate.
    72. Multi-Language CMAS Alerting. The WARN Act required the CMSAAC 
to submit recommendations to the Commission regarding ``the technical 
capability to transmit emergency alerts by electing commercial mobile 
providers to subscribers in languages in addition to English, to the 
extent practical and feasible.'' In the CMAS NPRM, the Commission 
sought comment on the technical feasibility of providing commercial 
mobile alerts in

[[Page 43110]]

languages in addition to English, including how the provision of alerts 
in multiple languages could affect the generation and distribution of 
messages on a local, state, and national level. Based on the record 
before us, the Commission finds that it would be premature to require 
CMS providers to transmit alerts in languages in addition to English. 
As explained below, the Commission agrees with the CMSAAC and those 
commenters that state that further technical study is needed to enable 
the provision of alerts in multiple languages.
    73. The CMSAAC provided recommendations regarding multi-language 
alerting in section 5.7 of its report. The CMSAAC specifically 
``recognized that there is a strong desire for the CMAS to support 
Spanish in addition to English,'' but found that supporting multiple 
languages in the first generation of CMAS could adversely impact system 
capacity and increase message latency. It noted that while Spanish and 
English would cover 99 percent of all U.S. households, there are more 
than 37 languages in the United States that exceed 1 percent of 
households on a local level. The CMSAAC stated that delivering CMAS 
alerts in these languages would require mobile devices capable of 
supporting at least 16 different character sets. The CMSAAC also stated 
that some languages require two bytes per character rather than one 
byte per character for English, thereby further limiting message 
length. The CMSAAC found that the technical feasibility of providing 
alerts in languages in addition to English is a highly complex issue 
requiring further study. Finally, the CMSAAC noted that the CMAS 
architecture can support language extensions and recommended that this 
capability be reserved for future study.
    74. Several parties disagree that the technical feasibility of 
providing alerts in languages in addition to English requires further 
study, and urge us to mandate the provision of alerts in multiple 
languages now. The CAPUC notes that ``roughly 30.1 percent of 
California's population has limited English proficiency,'' and that the 
State ``uses different languages for different types of communications 
* * * [including] Spanish, Cantonese, Mandarin, Tagalog, Vietnamese, 
Korean, Farsi, Arabic, and Hmong.'' The CAPUC asserts ``that various 
commercial alert service providers represent that they can provide 
alerts in six different languages,'' but does not identify these 
service providers. There is no evidence in the record before us however 
of any CMS provider having the current capability to deliver alerts in 
six different languages, and the Commission therefore cannot adopt 
CAPUC's request that the Commission require transmission of alerts in a 
minimum of six languages.
    75. CellCast and One2many also urge us to implement multiple 
language alerting. CellCast notes that pending standards under the ITU 
for Message Indicators (MIs) can facilitate either the dedication of 
discrete MIs for specific languages, or the rejection of messages in 
undesired languages via the message preamble. CellCast suggests that 
such standards would provide clear direction for international 
harmonization of emergency alerting systems and handsets. CellCast 
further argues that the potential latency of multiple messages in 
sequential languages would be indiscernible to a mobile user and should 
not impact that user's ability to react to an emergency. CellCast 
claims that the delivery of multi-language alerts would not add any new 
burden on the Alert Aggregator or the CMS provider, and would not 
require any development of new technology. One2many states that there 
are numerous ``channels,'' or Message Identifiers, available in a cell 
broadcast. According to One2many, end users can activate their phones 
to receive messages on the channel number that matches their language.
    76. By contrast, most parties in this proceeding concur with the 
CMSAAC that further study of multiple language alerting is necessary. 
CTIA, for example, states that the Commission should not require 
electing CMS providers to transmit alerts in multiple languages because 
of limitations in providers' existing air interfaces, handset character 
sets, and traffic overflow. Regarding the varying air interfaces, 
Alltel concurs with the CMSAAC that transmitting multi-language alerts 
is not technically feasible for CDMA systems, subject to future review 
as technology improves. According to Alltel, GSM can support multiple 
channels for simultaneous broadcast and discrete channels could be 
dedicated to different languages. Alltel explains that CDMA lacks this 
capability and would require sequential broadcasts of alerts in 
multiple languages with the potential for unacceptable latency between 
broadcasts of the same language while alerts in multiple languages are 
sequentially broadcast.
    77. With respect to character set limitations in mobile devices, 
MetroPCS states that most handsets currently marketed in the United 
States use the Latin alphabet and would not support other languages--
and that adding such capabilities would create substantial burdens on 
electing CMS providers and manufacturers, while increasing the costs of 
handsets to consumers. The American Association of Paging Carriers 
similarly explains that parallel alerts in languages other than English 
would threaten network congestion, and complicate subscriber device 
designs and capabilities. T-Mobile adds that a multi-language 
requirement would impede CMAS deployment, and that until the technology 
improves to facilitate multiple languages, non-English speaking users 
could be prompted by an English alert to turn to sources in their 
respective languages for further information.
    78. Several parties, including AT&T, recommend that the Commission 
initially require alerts only in English, but also develop a national 
plan that provides federal, state, and local alert initiators with 
clear guidance on how alert initiators must craft multi-language alerts 
that reach the electing CMS Provider Gateways in a standardized format 
ready for end-user delivery without translation. The CAPUC, which 
advocates mandatory multi-language alerting, urges the Commission to 
examine whether latency or delivery concerns could be resolved if 
language receipt were part of a pre-subscription process. The Wireless 
RERC asks that the Commission encourage providers serving non-English 
speaking users to install software that will automatically translate 
English emergency messages into other languages, especially given the 
potential delay caused by an alert originator having to send out 
messages in multiple languages. These parties' insightful comments as 
well as those discussed above underscore that electing CMS providers 
face many technical challenges as they seek to implement alerting in 
languages in addition to English. Accordingly, the Commission concludes 
that further study is needed to develop capabilities for providing 
alerts in multiple languages, and does not require provision of alerts 
in any language other than English at this time. The Commission 
encourages the wireless industry and the public safety community to 
expeditiously develop and implement capabilities to deliver alerts in 
languages in addition to English.
    79. Roaming. The Commission agrees with the CMSAAC and the majority 
of commenting parties that the public interest will be served by 
requiring participating CMS providers to support CMAS alerting when 
subscribers are receiving services through roaming. As discussed 
further below, the Commission finds that adopting such a

[[Page 43111]]

requirement is consistent with its responsibility under the WARN Act to 
enable commercial mobile service alerting, as well as its duty under 
Executive Order 13407 to ``adopt rules to ensure that communications 
systems have the capacity to transmit alerts and warnings to the public 
as part of the public alert and warning system.''
    80. In the Automatic Roaming Order, the Commission found that 
``consumers have come to expect seamless wireless service wherever they 
travel within the United States and, ultimately, this will be achieved 
through automatic roaming.'' Thus, as a general matter, mobile device 
users will anticipate that the alerting features and services available 
to them in their home market will be available when roaming. Under the 
rules the Commission adopts, when a subscriber receives services 
pursuant to a roaming agreement and the operator of the roamed upon 
network is a participating CMS provider, the subscriber will receive 
alert messages, provided the subscriber's mobile device is configured 
for and technically capable of receiving alert messages from the roamed 
upon network.
    81. Preemption of Calls in Progress. The CMSAAC recommended that 
CMAS alerts not preempt ongoing voice or data sessions. The Commission 
agrees with this recommendation. It believes that it would be contrary 
to the public interest if alert messages were to preempt certain active 
voice or data sessions. During a crisis, such as a terrorist attack, 
many individuals will be seeking emergency aid related to the actual 
event and other emergencies. In either circumstance, the public would 
be ill served if their calls for urgent aid were summarily preempted. 
In light of this, the Commission will require that any device marketed 
as ``CMAS compliant'' must not permit an alert to preempt an ongoing 
call.
    82. Service Profiles. In its recommendations, the CMSAAC introduced 
the concept of technology-neutral service profiles for emergency 
alerts, each containing, for example, information on maximum payload 
and displayable message size. The CMSAAC further recommended specific 
service profiles for: (a) Text; (b) Streaming Audio (future 
capability); (c) Streaming Video (future capability); and (c) 
Downloaded Multimedia Profile (future capability), and provided general 
recommendations and conclusions for each. In the CMAS NPRM, the 
Commission sought comment on the service profiles recommended by the 
CMSAAC. The Commission agrees with those commenters who argue that it 
should adopt the CMSAAC's recommendation that text-only alerts are 
appropriate for an initial system. Because the Commission believes that 
it would be premature and not consistent with its obligations under 
section 602(a) of the WARN Act to adopt standards and requirements for 
technologies that are still under development, this Order will not 
address future technologies such as streaming audio, video and 
downloadable multimedia. Rather, this Order will only address CMSAAC 
recommended profiles for text.
    83. As part of the text profile, the CMSAAC recommended a maximum 
displayable message size of 90 characters. The Commission sought 
comment on this recommendation in the CMAS NPRM. Several commenters 
support the CMSAAC's recommendation. For example, AT&T states that, 
``given the current technical limitations in delivering emergency 
alerts, during the nascent stages of the CMAS the Commission should 
limit alerts to 90 characters * * *'' Motorola supports this view and 
notes that inclusion of additional information and characters beyond 90 
characters will strain the network, causing few people to receive the 
alert. AAPC states that the 90 character limit strikes an appropriate 
balance between complexity and a reasonably constructed CMAS. Other 
commenters raised concerns that a 90 character limit would not provide 
sufficient information to subscribers about emergencies. For example, 
CellCast states in their comments that 90 characters alone is 
insufficient to convey a complete alert to mobile devices. Furthermore, 
one commenter stated that the ``character count recommendations are 
reasonable for display of `basic' warnings but CMSAAC recommendations 
should accommodate supplemental and verbose message formats.''
    84. The Commission concludes that, at this initial stage, adoption 
of a 90 character limit serves the public interest. The Commission 
agrees with commenters such as MetroPCS that a 90 character limit will 
allow all systems to transmit the message with minimal change, and that 
90 characters is an effective limit to allow the message to be 
delivered and actually be read. As the CMSAAC concluded and the 
Wireless Rehabilitation Engineering Research Center (WRERC) notes, the 
90 character text limit of any CMAS alert is reasonable because the 
CMAS alert is intended to get the attention of a person. The person can 
then seek out other media for confirmation of the alert and more 
information.
    85. The CMSAAC also recommended that where the alert coming into 
the Alert Gateway contains a link to an Internet Web site (or URL) as a 
resource element, the Alert Gateway would retrieve any file specified 
by the URL and deliver that file to the CMS Provider Gateway. This is a 
different issue from the URL in free text issue discussed above, 
because it implicates the manner in which the alert is sent to the CMS 
Provider Gateway, as opposed to the actual content of the alert itself. 
The Commission agrees with the CMSAAC that CMS provider networks do not 
have the resources to process alerts with internet links. Further, URLs 
may link the CMS Provider Gateway to untrusted Internet sites that 
could fall outside the security requirements that the electing CMS 
providers have indicated are an essential element of the CMAS. 
Accordingly, in the CMS provider profile, no alerts with internal URLs 
may be accepted. Rather, related files or other resource elements must 
be provided separately by the Alert Gateway to the CMS Provider 
Gateway.
    86. The Commission also adopts the CMSAAC observation that the CMAS 
profiles will not be able to accommodate real-time content, including a 
Presidential alert, even in text format. The Commission believes that 
the CMSAAC has given sufficient indication of the limits of current CMS 
provider architecture to support this conclusion. Currently, the only 
real-time alert that could potentially be provided to the CMAS is the 
Presidential alert (Emergency Alert Notification or EAN). In the event 
that such a significant event were to occur, all broadcast media would 
be carrying the message, and as the Wireless RERC recommends, 
instructing the public to tune to their local radio and television 
station and other mass media is the best option for obtaining 
additional emergency information.
    87. The text profiles the Commission adopts are reflected in table 
below:

[[Page 43112]]



                                                  Text Profile
----------------------------------------------------------------------------------------------------------------
            Attribute Name                    Attribute Definition                         Note
----------------------------------------------------------------------------------------------------------------
                               Service Profile: Text--Universal--Service--Profile
----------------------------------------------------------------------------------------------------------------
Purpose..............................  Common denominator for text        ......................................
                                        messages.
Maximum Payload Size.................  120 bytes........................  Size is estimated.
Maximum Displayable Message Size.....  90 characters for an English       Languages other than English, or
                                        language CMA encoded with 7-bit    coding other then 7-bit coding, will
                                        encoding.                          result in a change to the maximum
                                                                           number of characters supported.
Data Coding Scheme...................  UTF-8 as defined in IETF RFC-3629  The text provided over the C interface
                                                                           is provided in UTF-8 format which is
                                                                           capable of supporting text in English
                                                                           and other languages. It is the
                                                                           responsibility of the CMS Provider
                                                                           Gateway to translate to any character
                                                                           format encoding required by the CMS
                                                                           provider selected delivery
                                                                           technology.
----------------------------------------------------------------------------------------------------------------

    88. Security for CMAS Alerts. The CMSAAC recommended a specific 
Alert Aggregator and Alert Gateway Trust Model to assure the security, 
authentication and authorization of alerts from the Alert initiator to 
the CMS Provider Gateway. The CMSAAC also recommended security 
requirements for communications across the ``C'' interface between the 
Alert Gateway and CMS Provider Gateways and within each CMS provider's 
network. For example, the CMSAAC recommended that communications across 
the ``C'' interface be IP based. According to the CMSAAC, the security 
of the Reference Point C interface should be based upon standard IP 
security mechanisms such as VPN tunnels and IPSEC functionalities.
    89. The Commission finds that an IP-based communications across the 
``C'' interface serves the public interest because it would enhance the 
security of the CMAS. Accordingly, the Commission adopts the CMSAAC's 
recommendation. It disagrees with Purple Tree Technologies' concerns 
that the protocols put forth are insufficient to provide the security 
required, and that a higher layer security protocol is necessary over 
the ``C'' interface between the Alert and CMS Provider Gateways. 
Rather, the Commission agrees with Verizon Wireless, which in its Reply 
Comments rejects such a need. As Verizon Wireless correctly points out, 
under the CMAS Reference Architecture, which the Commission has adopted 
in this Order, the need for higher layer security protocols exists only 
as an element of the ``Trust Model,'' which addresses the linkage 
between the Alert Gateway and alert initiators. By the time the Alert 
Gateway hands off a particular alert to the CMS Provider Gateway, any 
necessary authentication and authorization has been completed, thus 
obviating the need for a higher level security layer over the ``C'' 
interface.
    90. The CMSAAC recommended that the security at Reference Points D 
and E be based upon CMS provider policies and upon the capabilities of 
the CMS provider selected delivery technologies. No commenter opposes 
this recommendation, and the Commission believes that the 
recommendation is consistent with the technologically neutral policy of 
this Order and is consistent with section 602(a) of the WARN Act which 
requires that the Commission adopt technical requirements necessary to 
facilitate emergency alert capabilities of CMS providers. Accordingly, 
the Commission adopts this recommendation of the CMSAAC.
    91. CMAS Reliability and Performance. The CMSAAC made general 
recommendations concerning CMAS system performance requirements. Most 
requirements are prospective observations and recommendations. Major 
ones include:
     Alert Gateway capacity. Based on historical data, the 
CMSAAC made certain predictions concerning Alert Gateway performance 
requirements, including the capability to monitor system utilization 
for capacity planning purposes, and to temporarily disable and buffer 
CMAS alert traffic in the event of an overload.
     Assessing latency in alert delivery. The CMSAAC stated 
that such an assessment would be difficult to make prior to deployment, 
but notes certain relevant factors, including: Mobile device battery 
life impact, call processing impact; capabilities of the delivery 
technology; message queues; number of languages; number of targeted 
cell sites/paging transceivers for the alert area; and any geo-
targeting processing.
     End-to-end reliability. The CMSAAC recommends that the 
CMAS end-to-end reliability technology meet telecom standards for 
highly reliable systems, but notes that the over-all reliability of 
CMAS is unpredictable because RF transmissions can be subject to noise 
and other interference or environmental factors; the capabilities of 
the cellular environment are not predictable especially in a disaster 
environment; the subscriber may be in a location that does not have any 
RF signal; and the subscriber's mobile device may not have any 
remaining power.
    92. In order to assure the reliability and performance of this new 
system, the CMSAAC recommended procedures for logging CMAS alerts at 
the Alert Gateway and for testing the system at the Alert Gateway and 
on an end-to-end basis. Because this presumes the existence of an 
entity acting in the role of Alert Aggregator/Gateway, the Commission 
cannot adopt rules in this area at this time.
    93. Timeline for Implementation of Technical Requirements, 
Standards and Protocols. In its recommendations, the CMSAAC proposed a 
specific timeline for the implementation of the CMAS. According to the 
CMSAAC, it would take a minimum of 24 months from the date by which CMS 
providers must elect to participate in the CMAS under section 
602(b)(2)(A) of the WARN Act to deploy the CMAS. The CMSAAC proposed 
deployment timeline was based upon the assumptions that (1) the CMSAAC 
recommendations contained within this document are accepted without any 
major technical changes and (2) the government documentation and 
deliverables are available at the milestone dates indicated on the 
timeline. In this regard, the CMSAAC also assumed that the 
requirements, development, and deployments of the Alert Gateway and 
Alert Aggregator would align with the CMS provider developments to 
allow for testing during the development process and prior to CMAS 
deployments. The CMSAAC

[[Page 43113]]

recommended timeline assumed that Federal Government interface 
specifications would be available in January, 2008, 10 months before 
CMAS development and testing was to begin.
    94. At the outset the Commission notes that the majority of 
commenters that addressed the issue supported the CMSAAC's proposed 
deployment timeline. Further, in its comments, FEMA asked the 
Commission not to adopt an effective date for these rules until all 
legal issues regarding the Federal government's role in the CMAS have 
been identified and resolved. In making this request, FEMA provided no 
indication as to when it believes such issues may be resolved.
    95. Issues related to the CMSAAC proposed timeline fall under the 
election provisions of section 602(b) of the WARN Act, and so are not 
strictly within the purview of this initial technical Order that 
complies with section 602(a). However, the Commission agrees with the 
CMSAAC that the Alert Aggregator and Alert Gateway must be in place in 
order for CMS providers to complete development of the CMAS and to 
begin receiving and transmitting emergency alerts.
    96. The Federal Alert Aggregator and Alert Gateway will make the 
Government Interface Design specifications available. In accordance 
with the CMSAAC proposed timeline, CMS providers must begin development 
and testing of the CMAS in a manner consistent with the rules adopted 
in the CMAS First Report and Order no later than 10 months from the 
date that the Alert Aggregator/Alert Gateway makes the Government 
Interface Design specifications available. This time period is 
consistent with the 10 months the CMSAAC proposed timeline indicates 
would elapse between the availability of the Aggregator/Gateway 
interface design specification and the beginning of CMAS development 
and testing. The Commission believes that this will give the government 
and industry stakeholders sufficient time to begin development, 
including the federal government's role. It will also give electing CMS 
providers adequate time to come into compliance with the rules adopted 
herein.

Procedural Matters

A. Final Paperwork Reduction Act Analysis

    97. This Report and Order may contain new information collection 
requirements subject to the Paperwork Reduction Act of 1995 (PRA), 
Public Law 104-13. If the Commission determines that the Report and 
Order contains collection subject to the PRA, it will be submitted to 
the Office of Management and Budget (OMB) for review under section 
3507(d) of the PRA at an appropriate time. At that time, OMB, the 
general public, and other Federal agencies will be invited to comment 
on the new or modified information collection requirements contained in 
this proceeding. In addition, the Commission notes that pursuant to the 
Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 
U.S.C. 3506(c)(4), the Commission previously sought specific comment on 
how the Commission might ``further reduce the information collection 
burden for small business concerns with fewer than 25 employees.''

B. Report to Congress

    98. The Commission will send a copy of the CMAS First Report and 
Order in a report to be sent to Congress and the Government 
Accountability Office pursuant to the Congressional Review Act, see 5 
U.S.C. 801(a)(1)(A).

Final Regulatory Flexibility Analysis

    99. As required by the Regulatory Flexibility Act of 1980, as 
amended (RFA), an Initial Regulatory Flexibility Analysis (IRFA) was 
incorporated in the Notice of Proposed Rulemaking in PSHSB Docket 07-
287 (CMAS NPRM). The Commission sought written public comments on the 
proposals in the CMAS NPRM, including comment on the IRFA. Comments on 
the IRFA were to have been explicitly identified as being in response 
to the IRFA and were required to be filed by the same deadlines as that 
established in section IV of the CMAS NPRM for other comments to the 
CMAS NPRM. The Commission sent a copy of the CMAS NPRM, including the 
IRFA, to the Chief Counsel for Advocacy of the Small Business 
Administration (SBA). In addition, the CMAS NPRM and IRFA were 
published in the Federal Register.

Need for, and Objectives of, the Order

    100. Section 602(a) of the WARN Act requires the Commission to 
``complete a proceeding to adopt relevant technical standards, 
protocols, procedures, and other technical requirements based on the 
recommendations of [the Commercial Mobile Service Alert Advisory 
Committee (CMSAAC)] necessary to enable commercial mobile service 
alerting capability for commercial mobile service providers that 
voluntarily elect to transmit emergency alerts.'' Although the CMAS 
NPRM solicited comment on issues related to section 602(b) (CMS 
provider election to the CMAS) or 602(c) (Public Television Station 
equipment requirements), the CMAS First Report and Order only addresses 
issues raised by section 602(a) of the WARN Act. Accordingly, this FRFA 
only addressees the manner in which any commenters to the IRFA 
addressed the Commission's adoption of technical standards, 
requirements and protocols for the CMAS as required by section 602(a) 
of the WARN Act.
    101. The CMAS First Report and Order adopts rules necessary to 
enable CMS alerting capability for CMS providers who elect to transmit 
emergency alerts to their subscribers. The Order adopts technologically 
neutral rules governing the CMS provider-related functions and 
responsibilities with respect to the CMAS. Specifically, the rules 
address the CMS providers' functions within the CMAS, including CMS 
provider-controlled elements within the CMAS architecture, emergency 
alert formatting, classes and elements, geographic targeting (geo-
targeting) and accessibility for people with disabilities and the 
elderly.

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

    102. There were no comments filed that specifically addressed the 
IRFA. The only commenter that explicitly identified itself as a small 
business was Interstate Wireless, Inc., which supported the 
Commission's adoption of the CMSAAC's recommendations. Although 
Interstate Wireless did not comment specifically on the IRFA, it did 
state that the cost of building and maintaining a CMS Provider Gateway 
would be more than it and other similarly situated Small Business CMS 
providers could afford and still be able to provide the alert service 
to the public without cost. Accordingly, Interstate Wireless requested 
that the Federal Government either provide the proper software and 
reception equipment for the CMS Provider Gateways, or provide grants to 
the Small Business CMS providers to purchase, install, and maintain the 
equipment themselves. In paragraph 19, note 58 of the CMAS First Report 
and Order the Commission notes that questions of funding are not 
addressed by section 602(a) of the WARN Act and are outside of the 
scope of this Order.

[[Page 43114]]

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

    103. The RFA directs agencies to provide a description of, and, 
where feasible, an estimate of, the number of small entities that may 
be affected by the rules adopted herein. The RFA generally defines the 
term ``small entity'' as having the same meaning as the terms ``small 
business,'' ``small organization,'' and ``small governmental 
jurisdiction.'' In addition, the term ``small business'' has the same 
meaning as the term ``small business concern'' under the Small Business 
Act. A ``small business concern'' is one which: (1) Is independently 
owned and operated; (2) is not dominant in its field of operation; and 
(3) satisfies any additional criteria established by the Small Business 
Administration (SBA).
    104. Wireless Telecommunications Carriers (except Satellite). Since 
2007, the SBA has recognized wireless firms within this new, broad, 
economic census category. Prior to that time, the SBA had developed a 
small business size standard for wireless firms within the now-
superseded census categories of ``Paging'' and ``Cellular and Other 
Wireless Telecommunications.'' Under the present and prior categories, 
the SBA has deemed a wireless business to be small if it has 1,500 or 
fewer employees. Because Census Bureau data are not yet available for 
the new category, the Commission estimates small business prevalence 
using the prior categories and associated data. For the first category 
of Paging, data for 2002 show that there were 807 firms that operated 
for the entire year. Of this total, 804 firms had employment of 999 or 
fewer employees, and three firms had employment of 1,000 employees or 
more. For the second category of Cellular and Other Wireless 
Telecommunications, data for 2002 show that there were 1,397 firms that 
operated for the entire year. Of this total, 1,378 firms had employment 
of 999 or fewer employees, and 19 firms had employment of 1,000 
employees or more. Thus, using the prior categories and the available 
data, the Commission estimates that the majority of wireless firms can 
be considered small.
    105. Cellular Service. As noted, the SBA has developed a small 
business size standard for small businesses in the category ``Wireless 
Telecommunications Carriers (except satellite).'' Under that SBA 
category, a business is small if it has 1,500 or fewer employees. Since 
2007, the SBA has recognized wireless firms within this new, broad, 
economic census category. Prior to that time, the SBA had developed a 
small business size standard for wireless firms within the now-
superseded census categories of ``Paging'' and ``Cellular and Other 
Wireless Telecommunications.'' Accordingly, the pertinent data for this 
category is contained within the prior Wireless Telecommunications 
Carriers (except Satellite) category.
    106. Auctions. Initially, the Commission notes that, as a general 
matter, the number of winning bidders that qualify as small businesses 
at the close of an auction does not necessarily represent the number of 
small businesses currently in service. Also, the Commission does not 
generally track subsequent business size unless, in the context of 
assignments or transfers, unjust enrichment issues are implicated.
    107. Broadband Personal Communications Service. The broadband 
Personal Communications Service (PCS) spectrum is divided into six 
frequency blocks designated A through F, and the Commission has held 
auctions for each block. The Commission has created a small business 
size standard for Blocks C and F as an entity that has average gross 
revenues of less than $40 million in the three previous calendar years. 
For Block F, an additional small business size standard for ``very 
small business'' was added and is defined as an entity that, together 
with its affiliates, has average gross revenues of not more than $15 
million for the preceding three calendar years. These small business 
size standards, in the context of broadband PCS auctions, have been 
approved by the SBA. No small businesses within the SBA-approved small 
business size standards bid successfully for licenses in Blocks A and 
B. There were 90 winning bidders that qualified as small entities in 
the C Block auctions. A total of 93 ``small'' and ``very small'' 
business bidders won approximately 40 percent of the 1,479 licenses for 
Blocks D, E, and F. On March 23, 1999, the Commission reauctioned 155 
C, D, E, and F Block licenses; there were 113 small business winning 
bidders. On January 26, 2001, the Commission completed the auction of 
422 C and F PCS licenses in Auction 35. Of the 35 winning bidders in 
this auction, 29 qualified as ``small'' or ``very small'' businesses. 
Subsequent events concerning Auction 35, including judicial and agency 
determinations, resulted in a total of 163 C and F Block licenses being 
available for grant.
    108. Narrowband Personal Communications Service. The Commission 
held an auction for Narrowband Personal Communications Service (PCS) 
licenses that commenced on July 25, 1994, and closed on July 29, 1994. 
A second commenced on October 26, 1994 and closed on November 8, 1994. 
For purposes of the first two Narrowband PCS auctions, ``small 
businesses'' were entities with average gross revenues for the prior 
three calendar years of $40 million or less. Through these auctions, 
the Commission awarded a total of forty-one licenses, 11 of which were 
obtained by four small businesses. To ensure meaningful participation 
by small business entities in future auctions, the Commission adopted a 
two-tiered small business size standard in the Narrowband PCS Second 
Report and Order. A ``small business'' is an entity that, together with 
affiliates and controlling interests, has average gross revenues for 
the three preceding years of not more than $40 million. A ``very small 
business'' is an entity that, together with affiliates and controlling 
interests, has average gross revenues for the three preceding years of 
not more than $15 million. The SBA has approved these small business 
size standards. A third auction commenced on October 3, 2001 and closed 
on October 16, 2001. Here, five bidders won 317 (MTA and nationwide) 
licenses. Three of these claimed status as a small or very small entity 
and won 311 licenses.
    109. Wireless Communications Services. This service can be used for 
fixed, mobile, radiolocation, and digital audio broadcasting satellite 
uses in the 2305-2320 MHz and 2345-2360 MHz bands. The Commission 
defined ``small business'' for the wireless communications services 
(WCS) auction as an entity with average gross revenues of $40 million 
for each of the three preceding years, and a ``very small business'' as 
an entity with average gross revenues of $15 million for each of the 
three preceding years. The SBA has approved these definitions. The 
Commission auctioned geographic area licenses in the WCS service. In 
the auction, which commenced on April 15, 1997 and closed on April 25, 
1997, there were seven bidders that won 31 licenses that qualified as 
very small business entities, and one bidder that won one license that 
qualified as a small business entity.
    110. 700 MHz Guard Bands Licenses. In the 700 MHz Guard Bands 
Order, the Commission adopted size standards for ``small businesses'' 
and ``very small businesses'' for purposes of determining their 
eligibility for special provisions such as bidding credits and 
installment payments. A small business in this service is an entity 
that, together with its affiliates and controlling principals, has 
average gross revenues not

[[Page 43115]]

exceeding $40 million for the preceding three years. Additionally, a 
``very small business'' is an entity that, together with its affiliates 
and controlling principals, has average gross revenues that are not 
more than $15 million for the preceding three years. SBA approval of 
these definitions is not required. An auction of 52 Major Economic Area 
(MEA) licenses for each of two spectrum blocks commenced on September 
6, 2000, and closed on September 21, 2000. Of the 104 licenses 
auctioned, 96 licenses were sold to nine bidders. Five of these bidders 
were small businesses that won a total of 26 licenses. A second auction 
of remaining 700 MHz Guard Bands licenses commenced on February 13, 
2001, and closed on February 21, 2001. All eight of the licenses 
auctioned were sold to three bidders. One of these bidders was a small 
business that won a total of two licenses. Subsequently, in the 700 MHz 
Second Report and Order, the Commission reorganized the licenses 
pursuant to an agreement among most of the licensees, resulting in a 
spectral relocation of the first set of paired spectrum block licenses, 
and an elimination of the second set of paired spectrum block licenses 
(many of which were already vacant, reclaimed by the Commission from 
Nextel). A single licensee that did not participate in the agreement 
was grandfathered in the initial spectral location for its two licenses 
in the second set of paired spectrum blocks. Accordingly, at this time 
there are 54 licenses in the 700 MHz Guard Bands.
    111. 700 MHz Band Commercial Licenses. There is 80 megahertz of 
non-Guard Band spectrum in the 700 MHz Band that is designated for 
commercial use: 698-757, 758-763, 776-787, and 788-793 MHz Bands. With 
one exception, the Commission adopted criteria for defining two groups 
of small businesses for purposes of determining their eligibility for 
bidding credits at auction. These two categories are: (1) ``small 
business,'' which is defined as an entity that has attributed average 
annual gross revenues that do not exceed $15 million during the 
preceding three years; and (2) ``very small business,'' which is 
defined as an entity with attributed average annual gross revenues that 
do not exceed $40 million for the preceding three years. In Block C of 
the Lower 700 MHz Band (710-716 MHz and 740-746 MHz), which was 
licensed on the basis of 734 Cellular Market Areas, the Commission 
adopted a third criterion for determining eligibility for bidding 
credits: an ``entrepreneur,'' which is defined as an entity that, 
together with its affiliates and controlling principals, has average 
gross revenues that are not more than $3 million for the preceding 
three years. The SBA has approved these small size standards.
    112. An auction of 740 licenses for Blocks C (710-716 MHz and 740-
746 MHz) and D (716-722 MHz) of the Lower 700 MHz Band commenced on 
August 27, 2002, and closed on September 18, 2002. Of the 740 licenses 
available for auction, 484 licenses were sold to 102 winning bidders. 
Seventy-two of the winning bidders claimed small business, very small 
business, or entrepreneur status and won a total of 329 licenses. A 
second auction commenced on May 28, 2003, and closed on June 13, 2003, 
and included 256 licenses: Five EAG licenses and 251 CMA licenses. 
Seventeen winning bidders claimed small or very small business status 
and won 60 licenses, and nine winning bidders claimed entrepreneur 
status and won 154 licenses.
    113. The remaining 62 megahertz of commercial spectrum is currently 
scheduled for auction on January 24, 2008. As explained above, bidding 
credits for all of these licenses will be available to ``small 
businesses'' and ``very small businesses.''
    114. Advanced Wireless Services. In the AWS-1 Report and Order, the 
Commission adopted rules that affect applicants who wish to provide 
service in the 1710-1755 MHz and 2110-2155 MHz bands. The Commission 
did not know precisely the type of service that a licensee in these 
bands might seek to provide. Nonetheless, the Commission anticipated 
that the services that will be deployed in these bands may have capital 
requirements comparable to those in the broadband Personal 
Communications Service (PCS), and that the licensees in these bands 
will be presented with issues and costs similar to those presented to 
broadband PCS licensees. Further, at the time the broadband PCS service 
was established, it was similarly anticipated that it would facilitate 
the introduction of a new generation of service. Therefore, the AWS-1 
Report and Order adopts the same small business size definition that 
the Commission adopted for the broadband PCS service and that the SBA 
approved. In particular, the AWS-1 Report and Order defines a ``small 
business'' as an entity with average annual gross revenues for the 
preceding three years not exceeding $40 million, and a ``very small 
business'' as an entity with average annual gross revenues for the 
preceding three years not exceeding $15 million. The AWS-1 Report and 
Order also provides small businesses with a bidding credit of 15 
percent and very small businesses with a bidding credit of 25 percent.
    115. Common Carrier Paging. As noted, the SBA has developed a small 
business size standard for wireless firms within the broad economic 
census category of ``Wireless Telecommunications Carriers (except 
Satellite).'' Under this category, the SBA deems a business to be small 
if it has 1,500 or fewer employees. Since 2007, the SBA has recognized 
wireless firms within this new, broad, economic census category. Prior 
to that time, the SBA had developed a small business size standard for 
wireless firms within the now-superseded census categories of 
``Paging'' and ``Cellular and Other Wireless Telecommunications.'' 
Under the present and prior categories, the SBA has deemed a wireless 
business to be small if it has 1,500 or fewer employees. Because Census 
Bureau data are not yet available for the new category, the Commission 
will estimate small business prevalence using the prior categories and 
associated data. For the first category of Paging, data for 2002 show 
that there were 807 firms that operated for the entire year. Of this 
total, 804 firms had employment of 999 or fewer employees, and three 
firms had employment of 1,000 employees or more. For the second 
category of Cellular and Other Wireless Telecommunications, data for 
2002 show that there were 1,397 firms that operated for the entire 
year. Of this total, 1,378 firms had employment of 999 or fewer 
employees, and 19 firms had employment of 1,000 employees or more. 
Thus, using the prior categories and the available data, the Commission 
estimates that the majority of wireless firms can be considered small. 
Thus, under this category, the majority of firms can be considered 
small.
    116. In the Paging Third Report and Order, the Commission developed 
a small business size standard for ``small businesses'' and ``very 
small businesses'' for purposes of determining their eligibility for 
special provisions such as bidding credits and installment payments. A 
``small business'' is an entity that, together with its affiliates and 
controlling principals, has average gross revenues not exceeding $15 
million for the preceding three years. Additionally, a ``very small 
business'' is an entity that, together with its affiliates and 
controlling principals, has average gross revenues that are not more 
than $3 million for the preceding three years. The SBA has approved 
these small business size standards. An auction of Metropolitan 
Economic Area licenses commenced on February 24, 2000, and

[[Page 43116]]

closed on March 2, 2000. Of the 985 licenses auctioned, 440 were sold. 
Fifty-seven companies claiming small business status won. Also, 
according to Commission data, 365 carriers reported that they were 
engaged in the provision of paging and messaging services. Of those, 
the Commission estimates that 360 are small, under the SBA-approved 
small business size standard.
    117. Wireless Communications Service. This service can be used for 
fixed, mobile, radiolocation, and digital audio broadcasting satellite 
uses. The Commission established small business size standards for the 
wireless communications services (WCS) auction. A ``small business'' is 
an entity with average gross revenues of $40 million for each of the 
three preceding years, and a ``very small business'' is an entity with 
average gross revenues of $15 million for each of the three preceding 
years. The SBA has approved these small business size standards. The 
Commission auctioned geographic area licenses in the WCS service. In 
the auction, there were seven winning bidders that qualified as ``very 
small business'' entities, and one that qualified as a ``small 
business'' entity.
    118. Wireless Communications Equipment Manufacturers. While these 
entities are merely indirectly affected by its action, the Commission 
describes them to achieve a fuller record. The Census Bureau defines 
this category as follows: ``This industry comprises establishments 
primarily engaged in manufacturing radio and television broadcast and 
wireless communications equipment. Examples of products made by these 
establishments are: Transmitting and receiving antennas, cable 
television equipment, GPS equipment, pagers, cellular phones, mobile 
communications equipment, and radio and television studio and 
broadcasting equipment.'' The SBA has developed a small business size 
standard for Radio and Television Broadcasting and Wireless 
Communications Equipment Manufacturing, which is: All such firms having 
750 or fewer employees. According to Census Bureau data for 2002, there 
were a total of 1,041 establishments in this category that operated for 
the entire year. Of this total, 1,010 had employment of under 500, and 
an additional 13 had employment of 500 to 999. Thus, under this size 
standard, the majority of firms can be considered small.
    119. Radio and Television Broadcasting and Wireless Communications 
Equipment Manufacturing. The Census Bureau defines this category as 
follows: ``This industry comprises establishments primarily engaged in 
manufacturing radio and television broadcast and wireless 
communications equipment. Examples of products made by these 
establishments are: Transmitting and receiving antennas, cable 
television equipment, GPS equipment, pagers, cellular phones, mobile 
communications equipment, and radio and television studio and 
broadcasting equipment.'' The SBA has developed a small business size 
standard for Radio and Television Broadcasting and Wireless 
Communications Equipment Manufacturing, which is: All such firms having 
750 or fewer employees. According to Census Bureau data for 2002, there 
were a total of 1,041 establishments in this category that operated for 
the entire year. Of this total, 1,010 had employment of under 500, and 
an additional 13 had employment of 500 to 999. Thus, under this size 
standard, the majority of firms can be considered small.
    120. Software Publishers. While these entities are merely 
indirectly affected by its action, the Commission is describing them to 
achieve a fuller record. These companies may design, develop or publish 
software and may provide other support services to software purchasers, 
such as providing documentation or assisting in installation. The 
companies may also design software to meet the needs of specific users. 
The SBA has developed a small business size standard of $23 million or 
less in average annual receipts for the category of Software 
Publishers. For Software Publishers, Census Bureau data for 2002 
indicate that there were 6,155 firms in the category that operated for 
the entire year. Of these, 7,633 had annual receipts of under $10 
million, and an additional 403 firms had receipts of between $10 
million and $24,999,999. For providers of Custom Computer Programming 
Services, the Census Bureau data indicate that there were 32,269 firms 
that operated for the entire year. Of these, 31,416 had annual receipts 
of under $10 million, and an additional 565 firms had receipts of 
between $10 million and $24,999,999. Consequently, the Commission 
estimates that the majority of the firms in this category are small 
entities that may be affected by its action.
    121. NCE and Public Broadcast Stations. The Census Bureau defines 
this category as follows: ``This industry comprises establishments 
primarily engaged in broadcasting images together with sound. These 
establishments operate television broadcasting studios and facilities 
for the programming and transmission of programs to the public.'' The 
SBA has created a small business size standard for Television 
Broadcasting entities, which is: Such firms having $13 million or less 
in annual receipts. According to Commission staff review of the BIA 
Publications, Inc., Master Access Television Analyzer Database as of 
May 16, 2003, about 814 of the 1,220 commercial television stations in 
the United States had revenues of $12 (twelve) million or less. The 
Commission notes, however, that in assessing whether a business concern 
qualifies as small under the above definition, business (control) 
affiliations must be included. The Commission's estimate, therefore, 
likely overstates the number of small entities that might be affected 
by the Commission's action, because the revenue figure on which it is 
based does not include or aggregate revenues from affiliated companies.
    122. In addition, an element of the definition of ``small 
business'' is that the entity not be dominant in its field of 
operation. The Commission is unable at this time to define or quantify 
the criteria that would establish whether a specific television station 
is dominant in its field of operation. Accordingly, the estimate of 
small businesses to which rules may apply do not exclude any television 
station from the definition of a small business on this basis and are 
therefore over-inclusive to that extent. Also as noted, an additional 
element of the definition of ``small business'' is that the entity must 
be independently owned and operated. The Commission notes that it is 
difficult at times to assess these criteria in the context of media 
entities and its estimates of small businesses to which they apply may 
be over-inclusive to this extent. There are also 2,117 low power 
television stations (LPTV). Given the nature of this service, the 
Commission will presume that all LPTV licensees qualify as small 
entities under the above SBA small business size standard.
    123. The Commission has, under SBA regulations, estimated the 
number of licensed NCE television stations to be 380. The Commission 
notes, however, that, in assessing whether a business concern qualifies 
as small under the above definition, business (control) affiliations 
must be included. The Commission's estimate, therefore, likely 
overstates the number of small entities that might be affected by its 
action, because the revenue figure on which it is based does not 
include or aggregate revenues from affiliated companies. The Commission 
does not compile and otherwise does not have access to information on 
the revenue of NCE stations that would permit it to

[[Page 43117]]

determine how many such stations would qualify as small entities.

Description of Projected Reporting, Recordkeeping, and Other Compliance 
Requirements

    124. This Report and Order may contain new information collection 
requirements subject to the Paperwork Reduction Act of 1995 (PRA), 
Public Law 104-13. If the Commission determines that the Report and 
Order contains collection subject to the PRA, it will be submitted to 
the Office of Management and Budget (OMB) for review under section 
3507(d) of the PRA at an appropriate time. At that time, OMB, the 
general public, and other Federal agencies will be invited to comment 
on the new or modified information collection requirements contained in 
this proceeding. In addition, the Commission notes that pursuant to the 
Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 
U.S.C. 3506(c)(4), the Commission previously sought specific comment on 
how the Commission might ``further reduce the information collection 
burden for small business concerns with fewer than 25 employees.

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

    125. The RFA requires an agency to describe any significant 
alternatives that it has considered in developing its approach, which 
may include the following four alternatives (among others): ``(1) The 
establishment of differing compliance or reporting requirements or 
timetables that take into account the resources available to small 
entities; (2) the clarification, consolidation, or simplification of 
compliance and reporting requirements under the rule for such small 
entities; (3) the use of performance rather than design standards; and 
(4) an exemption from coverage of the rule, or any part thereof, for 
such small entities.''
    126. As noted above, the CMAS First Report and Order deals only 
with the WARN Act section 602(a) requirement that the Commission adopt 
technical standards, protocols, procedures, and other technical 
requirements based on the recommendations of the Commercial Mobile 
Service Alert Advisory Committee. The entities affected by this Order 
were largely the members of the CMSAAC. In its formation of the CMSAAC, 
the Commission made sure to include representatives of small businesses 
among the advisory committee members. Also, as the Commission indicates 
by its treatment of the comments of Interstate Wireless above, the 
technical requirements, standards and protocols on which the Commission 
sought comment already contain concerns raised by small businesses. The 
WARN ACT NPRM also sought comment on a number of alternatives to the 
recommendations of the CMSAAC, such as the Digital EAS and FM sub-
carrier based alerts. In its consideration of these and other 
alternatives the CMSAAC recommendations, the Commission has attempted 
to impose minimal regulation on small entities to the extent consistent 
with the Commission's goal of advancing its public safety mission by 
adopting technical requirements, standards and protocols for a CMAS 
that CMS providers would elect to provide alerts and warnings to their 
customers. The affected CMS providers have overwhelmingly expressed 
their willingness to cooperate in the formation of the CMAS, and the 
Commission anticipates that the standards, protocols and requirement 
that it adopts in this Order will encourage CMS providers to work with 
other industry and government entities to complete and participate in 
the CMAS.

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

    127. None.

Report to Congress

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

Ordering Clauses

    129. It is ordered, that pursuant to sections 1, 4(i) and (o), 201, 
303(r), 403, and 706 of the Communications Act of 1934, as amended, 47 
U.S.C. 151, 154(i) and (o), 201, 303(r), 403, and 606, as well as by 
sections 602(a),(b),(c), (f), 603, 604 and 606 of the WARN Act, this 
Report and Order is hereby adopted. The rules adopted in this Report 
and Order shall become effective September 22, 2008, except that any 
new information collection requirements contained in these rules will 
not become effective prior to OMB approval. The Commission will publish 
a document in the Federal Register announcing the effective date of any 
information collections.
    130. It is further ordered that the Commission's Consumer and 
Government Affairs Bureau, Reference Information Center, shall send a 
copy of this Report and Order, including the Final Regulatory 
Flexibility Analysis, to the Chief Council for Advocacy of the Small 
Business Administration.

List of Subjects in 47 CFR Part 10

    Alert and warning, AMBER alert, Commercial mobile service provider.

Federal Communications Commission.
Marlene H. Dortch,
Secretary.

Final Rules

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

PART 10--COMMERCIAL MOBILE ALERT SYSTEM

Subpart A--General Information
Sec.
10.1 Basis.
10.2 Purpose.
10.10 Definitions.
10.11 CMAS Implementation Timeline.
Subpart B--Election To Participate in Commercial Mobile Alert System 
[Reserved]
Subpart C--System Architecture
10.300 Alert Aggregator [Reserved]
10.310 Federal Alert Gateway [Reserved]
10.320 Provider Gateway Requirements.
10.330 Provider Infrastructure Requirements.
Subpart D--Alert Message Requirements
10.400 Classification.
10.410 Prioritization.
10.420 Message Elements.
10.430 Character Limit.
10.440 Embedded Reference Prohibition.
10.450 Geographic Targeting.
10.460 Retransmission Frequency [Reserved]
10.470 Roaming.
Subpart E--Equipment Requirements
10.500 General Requirements.
10.510 Call Preemption Prohibition.
10.520 Common Audio Attention Signal.
10.530 Common Vibration Cadence.
10.540 Attestation Requirement [Reserved]

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

Subpart A--General Information


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

[[Page 43118]]

and Accountability for Every Port Act of 2006, Public Law 109-347, 
Titles I through III of the Communications Act of 1934, as amended, and 
Executive Order 13407 of June 26, 2006, Public Alert and Warning 
System, 71 FR 36975, June 26, 2006.


Sec.  10.2  Purpose.

    The rules in this part establish the requirements for participation 
in the voluntary Commercial Mobile Alert System.


Sec.  10.10  Definitions.

    (a) Alert Message. An Alert Message is a message that is intended 
to provide the recipient information regarding an emergency, and that 
meets the requirements for transmission by a Participating Commercial 
Mobile Service Provider under this part.
    (b) Common Alerting Protocol. The Common Alerting Protocol (CAP) 
refers to Organization for the Advancement of Structured Information 
Standards (OASIS) Standard CAP-V1.1, October 2005 (available at http://www.oasis-open.org/specs/index.php#capv1.1), or any subsequent version 
of CAP adopted by OASIS and implemented by the CMAS.
    (c) Commercial Mobile Alert System. The Commercial Mobile Alert 
System (CMAS) refers to the voluntary emergency alerting system 
established by this part, whereby Commercial Mobile Service Providers 
may elect to transmit Alert Messages to the public.
    (d) Commercial Mobile Service Provider. A Commercial Mobile Service 
Provider (or CMS Provider) is an FCC licensee providing commercial 
mobile service as defined in section 332(d)(1) of the Communications 
Act of 1934 (47 U.S.C. 332(d)(1)). Section 332(d)(1) defines the term 
commercial mobile service as any mobile service (as defined in 47 
U.S.C. 153) that is provided for profit and makes interconnected 
service available to the public or to such classes of eligible users as 
to be effectively available to a substantial portion of the public, as 
specified by regulation by the Commission.
    (e) County and County Equivalent. The terms County and County 
Equivalent as used in this part are defined by Federal Information 
Processing Standards (FIPS) 6-4, which provides the names and codes 
that represent the counties and other entities treated as equivalent 
legal and/or statistical subdivisions of the 50 States, the District of 
Columbia, and the possessions and freely associated areas of the United 
States. Counties are considered to be the ``first-order subdivisions'' 
of each State and statistically equivalent entity, regardless of their 
local designations (county, parish, borough, etc.). Thus, the following 
entities are considered to be equivalent to counties for legal and/or 
statistical purposes: The parishes of Louisiana; the boroughs and 
census areas of Alaska; the District of Columbia; the independent 
cities of Maryland, Missouri, Nevada, and Virginia; that part of 
Yellowstone National Park in Montana; and various entities in the 
possessions and associated areas. The FIPS codes and FIPS code 
documentation are available online at http://www.itl.nist.gov/fipspubs/index.htm.
    (f) Participating Commercial Mobile Service Provider. A 
Participating Commercial Mobile Service Provider (or a Participating 
CMS Provider) is a Commercial Mobile Service Provider that has 
voluntarily elected to transmit Alert Messages under subpart B of this 
part.


Sec.  10.11  CMAS Implementation Timeline.

    Notwithstanding anything in this part to the contrary, a 
Participating CMS provider shall begin development and testing of the 
CMAS in a manner consistent with the rules in this part no later than 
10 months from the date that the Federal Alert Aggregator and Alert 
Gateway makes the Government Interface Design specifications available.

Subpart B--Election to Participate in Commercial Mobile Alert 
System [Reserved]

Subpart C--System Architecture


Sec.  10.300  Alert Aggregator [Reserved]


Sec.  10.310  Federal Alert Gateway [Reserved]


Sec.  10.320  Provider Alert Gateway Requirements.

    This section specifies the functions that each Participating 
Commercial Mobile Service provider is required to support and perform 
at its CMS provider gateways.
    (a) General. The CMS provider gateway must provide secure, 
redundant, and reliable connections to receive Alert Messages from the 
Federal alert gateway. Each CMS provider gateway must be identified by 
a unique IP address or domain name.
    (b) Authentication and Validation. The CMS provider gateway must 
authenticate interactions with the Federal alert gateway, and validate 
Alert Message integrity and parameters. The CMS provider gateway must 
provide an error message immediately to the Federal alert gateway if a 
validation fails.
    (c) Security. The CMS provider gateway must support standardized 
IP-based security mechanisms such as a firewall, and support the 
defined CMAS ``C'' interface and associated protocols between the 
Federal alert gateway and the CMS provider gateway.
    (d) Geographic Targeting. The CMS provider gateway must determine 
whether the provider has elected to transmit an Alert Message within a 
specified alert area and, if so, map the Alert Message to an associated 
set of transmission sites.
    (e) Message Management.
    (1) Formatting. The CMS provider gateway is not required to perform 
any formatting, reformatting, or translation of an Alert Message, 
except for transcoding a text, audio, video, or multimedia file into 
the format supported by mobile devices.
    (2) Reception. The CMS provider gateway must support a mechanism to 
stop and start Alert Message deliveries from the Federal alert gateway 
to the CMS provider gateway.
    (3) Prioritization. The CMS provider gateway must process an Alert 
Message on a first in-first out basis except for Presidential Alerts, 
which must be processed before all non-Presidential alerts.
    (4) Distribution. A Participating CMS provider must deploy one or 
more CMS provider gateways to support distribution of Alert Messages 
and to manage Alert Message traffic.
    (5) Retransmission. The CMS provider gateway must manage and 
execute Alert Message retransmission, and support a mechanism to manage 
congestion within the CMS provider's infrastructure.
    (f) CMS Provider Profile. The CMS provider gateway will provide 
profile information on the CMS provider for the Federal alert gateway 
to maintain at the Federal alert gateway. This profile information must 
be provided by an authorized CMS provider representative to the Federal 
alert gateway administrator. The profile information must include the 
data listed in Table 10.320(f) and must comply with the following 
procedures:
    (1) The information must be provided 30 days in advance of the date 
when the CMS provider begins to transmit CMAS alerts.
    (2) Updates of any CMS provider profiles must be provided in 
writing at least 30 days in advance of the effective change date.

[[Page 43119]]



         Table 10.320(f).--CMSP Profile on Federal Alert Gateway
------------------------------------------------------------------------
                                    Parameter
       Profile parameter             election           Description
------------------------------------------------------------------------
CMSP Name.....................  .................  Unique identification
                                                    of CMSP.
CMSP gateway Address..........  IP address or      .....................
                                 Domain Name.
                                Alternate IP       Optional and subject
                                 address.           to implementation.
Geo-Location Filtering........  .........  If ``yes'' the only
                                                    CMAM issued in the
                                                    listed states will
                                                    be sent to the CMSP
                                                    gateway.
                                                   If ``no'', all CMAM
                                                    will be sent to the
                                                    CMSP gateway.
If yes, list of states........  CMAC Geocode for   List can be state
                                 state.             name or abbreviated
                                                    state name.
------------------------------------------------------------------------

Sec.  10.330  Provider Infrastructure Requirements.

    This section specifies the general functions that a Participating 
CMS Provider is required to perform within their infrastructure. 
Infrastructure functions are dependent upon the capabilities of the 
delivery technologies implemented by a Participating CMS Provider.
    (a) Distribution of Alert Messages to mobile devices.
    (b) Authentication of interactions with mobile devices.
    (c) Reference Points D & E. Reference Point D is the interface 
between a CMS Provider gateway and its infrastructure. Reference Point 
E is the interface between a provider's infrastructure and mobile 
devices including air interfaces. Reference Points D and E protocols 
are defined and controlled by each Participating CMS Provider.

Subpart D--Alert Message Requirements


Sec.  10.400  Classification.

    A Participating CMS Provider is required to receive and transmit 
three classes of Alert Messages: Presidential Alert; Imminent Threat 
Alert; and Child Abduction Emergency/AMBER Alert.
    (a) Presidential Alert. A Presidential Alert is an alert issued by 
the President of the United States or the President's authorized 
designee.
    (b) Imminent Threat Alert. An Imminent Threat Alert is an alert 
that meets a minimum value for each of three CAP elements: Urgency, 
Severity, and Certainty.
    (1) Urgency. The CAP Urgency element must be either Immediate 
(i.e., responsive action should be taken immediately) or Expected 
(i.e., responsive action should be taken soon, within the next hour).
    (2) Severity. The CAP Severity element must be either Extreme 
(i.e., an extraordinary threat to life or property) or Severe (i.e., a 
significant threat to life or property).
    (3) Certainty. The CAP Certainty element must be either Observed 
(i.e., determined to have occurred or to be ongoing) or Likely (i.e., 
has a probability of greater than 50 percent).
    (c) Child Abduction Emergency/AMBER Alert. (1) An AMBER Alert is an 
alert initiated by a local government official based on the U.S. 
Department of Justice's five criteria that should be met before an 
alert is activated:
    (i) Law enforcement confirms a child has been abducted;
    (ii) The child is 17 years or younger;
    (iii) Law enforcement believes the child is in imminent danger of 
serious bodily harm or death;
    (iv) There is enough descriptive information about the victim and 
the abduction to believe an immediate broadcast alert will help; and
    (v) The child's name and other data have been entered into the 
National Crime Information Center.
    (2) There are four types of AMBER Alerts: Family Abduction; Non-
family Abduction; Lost, Injured or Otherwise Missing; and Endangered 
Runaway.
    (i) Family Abduction. A Family Abduction (FA) alert involves an 
abductor who is a family member of the abducted child such as a parent, 
aunt, grandfather, or stepfather.
    (ii) Nonfamily Abduction. A Nonfamily Abduction (NFA) alert 
involves an abductor unrelated to the abducted child, either someone 
unknown to the child and/or the child's family or an acquaintance/
friend of the child and/or the child's family.
    (iii) Lost, Injured, or Otherwise Missing. A Lost, Injured, or 
Otherwise Missing (LIM) alert involves a case where the circumstances 
of the child's disappearance are unknown.
    (iv) Endangered Runaway. An Endangered Runaway (ERU) alert involves 
a missing child who is believed to have run away and in imminent 
danger.


Sec.  10.410  Prioritization.

    A Participating CMS Provider is required to transmit Presidential 
Alerts upon receipt. Presidential Alerts preempt all other Alert 
Messages. A Participating CMS Provider is required to transmit Imminent 
Threat Alerts and AMBER Alerts on a first in-first out (FIFO) basis.


Sec.  10.420  Message Elements.

    A CMAS Alert Message processed by a Participating CMS Provider 
shall include five mandatory CAP elements--Event Type; Area Affected; 
Recommended Action; Expiration Time (with time zone); and Sending 
Agency. This requirement does not apply to Presidential Alerts.


Sec.  10.430  Character Limit.

    A CMAS Alert Message processed by a Participating CMS Provider must 
not exceed 90 characters of alphanumeric text.


Sec.  10.440  Embedded Reference Prohibition.

    A CMAS Alert Message processed by a Participating CMS Provider must 
not include an embedded Uniform Resource Locator (URL), which is a 
reference (an address) to a resource on the Internet, or an embedded 
telephone number. This prohibition does not apply to Presidential 
Alerts.


Sec.  10.450  Geographic Targeting.

    This section establishes minimum requirements for the geographic 
targeting of Alert Messages. A Participating CMS Provider will 
determine which of its network facilities, elements, and locations will 
be used to geographically target Alert Messages. A Participating CMS 
Provider must transmit any Alert Message that is specified by a 
geocode, circle, or polygon to an area not larger than the provider's 
approximation of coverage for the Counties or County Equivalents with 
which that geocode, circle, or polygon intersects. If, however, the 
propagation area of a provider's transmission site exceeds a single 
County or County Equivalent, a Participating CMS Provider may transmit 
an Alert Message to an area not exceeding the propagation area.


Sec.  10.460 Retransmission Frequency  [Reserved]


Sec.  10.470  Roaming.

    When, pursuant to a roaming agreement (see Sec.  20.12 of this 
chapter), a subscriber receives services from a roamed-upon network of 
a Participating

[[Page 43120]]

CMS Provider, the Participating CMS Provider must support CMAS alerts 
to the roaming subscriber to the extent the subscriber's mobile device 
is configured for and technically capable of receiving CMAS alerts.

Subpart E--Equipment Requirements


Sec.  10.500  General Requirements.

    CMAS mobile device functionality is dependent on the capabilities 
of a Participating CMS Provider's delivery technologies. Mobile devices 
are required to perform the following functions:
    (a) Authentication of interactions with CMS Provider 
infrastructure.
    (b) Monitoring for Alert Messages.
    (c) Maintaining subscriber alert opt-out selections, if any.
    (d) Maintaining subscriber alert language preferences, if any.
    (e) Extraction of alert content in English or the subscriber's 
preferred language, if applicable.
    (f) Presentation of alert content to the device, consistent with 
subscriber opt-out selections. Presidential Alerts must always be 
presented.
    (g) Detection and suppression of presentation of duplicate alerts.


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


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


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


Sec.  10.540  Attestation Requirement [Reserved]

[FR Doc. E8-16853 Filed 7-23-08; 8:45 am]
BILLING CODE 6712-01-P