Commercial Mobile Alert System, 43099-43120 [E8-16853]

Agencies

• FEDERAL COMMUNICATIONS COMMISSION

[Federal Register Volume 73, Number 143 (Thursday, July 24, 2008)]
[Rules and Regulations]
[Pages 43099-43120]
From the Federal Register Online via the Government Printing 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 FCC@BCPIWEB.COM. Alternative formats (computer diskette, 
large print, audio cassette, and Braille) are available to persons with 
disabilities by sending an e-mail to FCC504@fcc.gov or calling the 
Consumer and Governmental Affairs Bureau at (202) 418-0530, TTY (202) 
418-0432. This document is also available on the Commission's Web site 
at https://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 ac