[Federal Register: July 24, 2008 (Volume 73, Number 143)]
[Rules and Regulations]
[Page 43099-43120]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr24jy08-9]
=======================================================================
-----------------------------------------------------------------------
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 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