**Before the**

**Federal Communications Commission**

**Washington, D.C. 20554**

+----------------------------------+----+------------------------------+
| In the Matter of                 | *  | PS Docket No. 07-287         |
|                                  | *) |                              |
| The Commercial Mobile Alert      | ** |                              |
| System                           |    |                              |
|                                  | *  |                              |
|                                  | *) |                              |
|                                  | ** |                              |
|                                  |    |                              |
|                                  | *  |                              |
|                                  | *) |                              |
|                                  | ** |                              |
|                                  |    |                              |
|                                  | *  |                              |
|                                  | *) |                              |
|                                  | ** |                              |
|                                  |    |                              |
|                                  | *  |                              |
|                                  | *) |                              |
|                                  | ** |                              |
+----------------------------------+----+------------------------------+

**FIRST REPORT AND ORDER**

**Adopted: April 9, 2008 Released: April 9, 2008**

By the Commission: Chairman Martin, and Commissioners Copps, Adelstein,
Tate and McDowell issuing separate statements.

Table of Contents

Heading Paragraph \#

I. iNTRODUCTION 1

II\. Background 5

III\. Discussion 7

A. Consideration of the CMSAAC Recommendations 8

B. CMAS Architecture and CMS Provider Functions 10

C. General CMAS Requirements 25

1\. Scope and Definition of CMAS Alerts 26

a\. Presidential Alerts 28

b\. Imminent Threat Alerts 29

c\. Child Abduction Emergency/AMBER Alerts 31

2\. Technologically Neutral Alert System 33

3\. CMAS Message Elements and Capabilities 41

a\. Required Alert Message Elements 41

b\. CMAS Generation of Free Text Alert Messages 44

4\. Geo-targeting CMAS Alerts 48

5\. Meeting the Needs of Users, Including Individuals with Disabilities
and the Elderly 57

6\. Output Mode/Display 68

7\. Message Retransmission 70

8\. Multi-Language CMAS Alerting 71

9\. Roaming 78

10\. Preemption of Calls in Progress 80

D. Service Profiles 81

E. Security for CMAS Alerts 87

F. CMAS Reliability and Performance 90

G. Timeline for Implementation of Technical Requirements, Standards and
Protocols. 92

IV\. Procedural Matters 96

A. Final Regulatory Flexibility Act Analysis 96

B. Final Paperwork Reduction Act of 1995 Analysis 97

C. Congressional Review Act Analysis 98

D. Alternative Formats 99

V. Ordering ClauseS 100

Appendix A - List Of Commenters

Appendix B - Final Regulatory Flexibility Analysis

Appendix C - Final Rules 50

# iNTRODUCTION

1.  This Commercial Mobile Alert System First Report and Order (CMAS
    First Report and Order) represents our next step in establishing a
    Commercial Mobile Alert System (CMAS), under which Commercial Mobile
    Service (CMS) providers[^1] may elect to transmit emergency alerts
    to the public. We take this step in compliance with section 602(a)
    of the WARN Act,[^2] which requires the Commission to adopt
    "relevant technical standards, protocols, procedures, and other
    technical requirements" based on the recommendations of the
    Commercial Mobile Service Alert Advisory Committee (CMSAAC)
    "necessary to enable commercial mobile service alerting capability
    for commercial mobile service providers that voluntarily elect to
    transmit emergency alerts."

2.  In this CMAS First Report and Order, we adopt rules necessary to
    enable CMS alerting capability for CMS providers who elect to
    transmit emergency alerts to their subscribers. Specifically, we
    adopt the architecture for the CMAS proposed by the CMSAAC and
    conclude that a Federal Government entity should aggregate,
    authenticate, and transmit alerts to the CMS providers.  In
    addition, we adopt technologically neutral rules governing:

-   *CMS provider-controlled elements within the CMAS architecture*
    (*e.g.*, the CMS Provider Gateway, CMS Provider infrastructure and
    mobile devices);

-   *Emergency alert formatting, classes, and elements*: Participating
    CMS Providers must transmit three classes of alerts - Presidential,
    Imminent Threat, and AMBER alerts;

-   *Geographic targeting (geo-targeting)*: Participating CMS Providers
    generally are required to target alerts at the county-level as
    recommended by the CMSAAC;

-   *Accessibility for people with disabilities and the elderly*:
    Participating CMS Providers must include an audio attention signal
    and vibration cadence on CMAS-capable handsets;

-   *Multi-language Alerting*: Participating CMS Providers will not be
    required at this time to transmit alerts in languages other than
    English;

-   *Availability of CMAS alerts while roaming*: Subscribers receiving
    services pursuant to a roaming agreement will receive alert messages
    on the roamed upon network if the operator of the roamed upon
    network is a Participating CMS provider and the subscriber\'s mobile
    device is configured for and technically capable of receiving alert
    messages from the roamed upon network;

-   *Preemption of calls in progress*: CMAS alerts may not preempt a
    voice or data session in progress;

-   *Initial implementation*: Participating CMS Providers must comply
    with these rules no later than 10 months from the date the FCC
    announces the selection of a Federal Government entity to perform
    the Alert Aggregator and Alert Gateway functions required to
    implement the CMAS.

3.  In adopting these rules today, we take a significant step towards
    implementing one of our highest priorities -- to ensure that all
    Americans have the capability to receive timely and accurate alerts,
    warnings and critical information regarding disasters and other
    emergencies irrespective of what communications technologies they
    use. As we have learned from disasters such as the 2005 hurricanes,
    such a capability is essential to enable Americans to take
    appropriate action to protect their families and themselves from
    loss of life or serious injury. This CMAS First Report and Order
    also is consistent with our obligation under Executive Order
    13407[^3] to "adopt rules to ensure that communications systems have
    the capacity to transmit alerts and warnings to the public as part
    of the public alert and warning system,"[^4] and our mandate under
    the Communications Act to promote the safety of life and property
    through the use of wire and radio communication.[^5]

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

# Background

5.  On October 13, 2006, the President signed the Security and
    Accountability For Every Port (SAFE Port) Act into law.[^9] Title VI
    of the SAFE Port Act, the Warning Alert and Response Network (WARN)
    Act, establishes a process for the creation of the CMAS whereby CMS
    providers may elect to transmit emergency alerts to their
    subscribers. The WARN Act requires that we undertake a series of
    actions to accomplish that goal, including requiring the Commission,
    by December 12, 2006 (within 60 days of enactment), to establish and
    convene an advisory committee to recommend system critical protocols
    and technical capabilities for the CMAS.[^10] Accordingly, we formed
    the CMSAAC, which had its first meeting on December 12, 2006.[^11]
    The WARN Act further required the CMSAAC to submit its
    recommendations to the Commission by October 12, 2007 (one year
    after enactment).[^12] The CMSAAC submitted its report to us on that
    date.[^13]

6.  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."[^14] On December 14, 2007, we released the Notice of
    Proposed Rulemaking[^15] requesting comment on, among other things,
    the technical requirements we should adopt to facilitate CMS
    providers' voluntary transmission of emergency alerts.[^16] We
    specifically invited comment on the CMSAAC's proposed technical
    requirements. Comments were due on February 4, 2008, with Reply
    Comments due on February 19, 2008.[^17]

# Discussion

7.  Consistent with section 602(a) of the WARN Act, today we adopt
    'technical standards, protocols, procedures and other technical
    requirements . . . necessary to enable commercial mobile service
    alerting capability for commercial mobile service providers that
    voluntarily elect to transmit emergency alerts."[^18] Specifically,
    the rules we adopt today address the CMS providers' functions within
    the CMAS, including CMS provider-controlled elements within the CMAS
    architecture, emergency alert formatting, classes and elements,
    geographic targeting (geo-targeting) and accessibility for people
    with disabilities and the elderly.[^19] In most cases, we have
    adopted rules generally based on the CMSAAC recommendations.[^20] In
    such cases, we find that the 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, we have determined
    that the public interest requires us to adopt requirements that are
    slightly different than those recommended by the CMSAAC.

## Consideration of the CMSAAC Recommendations 

8.  Several entities representing the wireless industry generally argue
    in their comments that the Commission has no authority to adopt
    technical requirements other than those proposed by the CMSAAC and
    that those must be adopted "as is." [^21] We disagree. The WARN Act
    does not require that we adopt the CMSAAC's recommendations
    verbatim. Rather, Congress required the Commission to adopt relevant
    technical requirements "based on recommendations of the
    CMSAAC."[^22] This indicates that while Congress intended that we
    give appropriate weight to the CMSAAC's recommendations in our
    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.[^23] 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.

9.  Commission discretion and flexibility in its adoption of the CMSAAC
    recommendations is also supported by the policy goal underlying the
    WARN Act, *i.e*., the creation of a CMAS in which CMS providers will
    elect to participate, and which will effectively deliver alerts and
    warnings to the public. The comments of Ericsson, with which we
    agree, support Commission discretion by stating that the technical
    standards and requirements we adopt for the CMAS should account for
    an evolving technology landscape.[^24] In order to account for
    changes in the wireless industry and maintain a technologically
    neutral approach to emergency alerting, the Commission must be able
    to apply the 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 

10. In its recommendations, the CMSAAC proposed the following
    architecture for the CMAS.[^25]

    **Functional Reference Model Diagram**

    ![](media/image1.png){width="0.28346456692913385in"
    height="0.7220472440944882in"}![](media/image2.wmf){width="0.3110236220472441in"
    height="0.17086614173228346in"}![](media/image3.png){width="0.5807086614173228in"
    height="0.752755905511811in"}![](media/image1.png){width="0.28346456692913385in"
    height="0.7228346456692913in"}![](media/image1.png){width="0.1700787401574803in"
    height="0.4334645669291339in"}![](media/image4.jpeg){width="0.539763779527559in"
    height="0.8082677165354331in"}

    Under this proposed reference model, a Federal government entity,
    the "Alert Aggregator," operating under a "Trust Model,"[^26] would
    receive, aggregate, and authenticate alerts originated by authorized
    alert initiators (*i.e.*, Federal, state, tribal and local
    government agencies) using the Common Alerting Protocol (CAP).[^27]
    The Federal government entity would also act as an "Alert
    Gateway"[^28] that would formulate a 90 character alert based on key
    fields in the CAP alert sent by the alert initiator.[^29] Based on
    CMS provider profiles maintained in the Alert Gateway, the Alert
    Gateway would then deliver the alert over a secure interface
    operated by the CMS provider[^30] to another gateway maintained by
    the appropriate CMS provider (CMS Provider Gateway).[^31] Each
    individual CMS Provider Gateway would be responsible for the
    management of the particular CMS provider elections to deliver
    alerts. The CMS Provider Gateway would also be responsible for
    formulating the alert in a manner consistent with the individual CMS
    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.[^32] As part of its recommended model, the CMSAAC also
    proposed technical standards defining the functions of the Alert
    Aggregator, Alert Gateway, CMS Provider Gateway, CMS infrastructure,
    CMS handsets and various interfaces (*i.e.*, A, B, C, D and E
    interfaces).[^33]

11. In the *CMAS NPRM*, we sought comment on the CMSAAC's proposed
    reference architecture, including its standards for defining the
    various element functions.[^34] 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).[^35] CellCast asserted that a
    national Aggregator/Gateway is not required for CMAS implementation
    and that there are multiple models for alert distribution that do
    not use such an element.[^36] DataFM and the National Association of
    Broadcasters (NAB) raised concerns that a national aggregator would
    create a single point of failure that would reduce CMAS resiliency
    and/or introduce unacceptable performance degradation.[^37]

12. According to the CMSAAC, a key element to CMS providers' ability to
    participate in the CMAS is the assumption of the Alert Aggregator
    and Alert Gateway functions by a Designated Federal Government
    Entity.[^38] Specifically, the CMSAAC recommended that the CMAS
    channel all Commercial Mobile Alert Messages (CMAMs) submitted by
    Federal, State, Tribal and local originators through a secure,
    Federal government administered, CAP-based alerting framework that
    would aggregate and hand off authenticated CMAMs to CMS Provider
    Gateways.[^39] We sought comment on this recommendation in the *CMAS
    NPRM*.[^40] The overwhelming majority of commenting parties
    supported the CMSAAC's recommendation.[^41] Most wireless carriers
    commenting on the issue stressed that this was essential to CMS
    providers' participation in the CMAS. ALLTEL, for example, stated
    that if "a federal government entity does not assume these roles,
    wireless service providers are less likely to participate" in the
    CMAS because "in an emergency situation it is imperative that
    wireless service providers are able to rely on a single source . . .
    and government officials are more appropriately trained in
    authenticating and constructing messages."[^42]

13. We adopt the CMSAAC's proposed architecture for the CMAS.[^43] We
    find that the recommended model will facilitate an effective and
    efficient means to transmit alerts and find that the public interest
    will be served as such. Contrary to APTS's assertions, nothing in
    section 602(a) of the WARN Act mandates that we only adopt
    requirements for CMS providers to opt into DEAS.[^44] While we agree
    with CellCast that there are other potential models for alert
    delivery by electing CMS providers, we note that none of those
    alternative solutions received the support of the CMSAAC. Moreover,
    we note that the CMSAAC recommendation is the result of consensus
    among commercial wireless carriers and their vendors, public safety
    agencies, organizations representing broadcast stations and
    organizations representing people with disabilities and the elderly,
    and other emergency alert experts. This consensus was reached after
    approximately ten months of deliberation. No other party has
    suggested an alternative that would be superior in meeting the needs
    of the commercial wireless industry and in ensuring that alerts are
    received by electing CMS providers and then are transmitted to their
    subscribers. In fact, both during the CMSAAC deliberations as well
    as throughout this proceeding, many wireless carriers have indicated
    that the inclusion of an alert aggregator and alert gateway function
    is essential to their participation in the voluntary CMAS.[^45]

14. Finally, we disagree with the concerns raised by DataFM and NAB that
    a national aggregator would necessarily create a single point of
    failure. While the CMSAAC recommended a single logical
    aggregator/gateway function, we expect that these functions will be
    implemented in a reliable and redundant fashion to maximize
    resiliency.[^46] Furthermore, given the volume of alerts expected
    for the CMAS, we believe that technology for processing alerts will
    not place a constraint on aggregator/gateway performance.[^47]
    Accordingly, we adopt the architecture proposed by the CMSAAC. As
    described below, however, we adopt as rules only those CMAS elements
    within the control of the CMS providers.

15. *Federal Government Role.* We agree with the CMSAAC and the majority
    of commenters that a Federally administered aggregator/gateway is a
    necessary element of a functioning CMAS. While no Federal agency has
    yet been identified to assume these two functions,[^48] we believe
    that a Federal government aggregator/gateway would offer the CMS
    providers the best possibility for the secure, accurate and
    manageable source of CMAS alerts that the WARN Act contemplates.

16. We believe that FEMA, some other entity within DHS, or NOAA may be
    in the best position to perform these functions.[^49] DHS, and more
    specifically FEMA, traditionally has been responsible for
    origination of Presidential alerts and administration of the
    EAS.[^50] Moreover, Executive Order 13407 gives DHS primary
    responsibility for implementing the United States' policy "to have
    an effective, reliable, integrated, flexible and comprehensive
    system to alert and warn the American people in situations of war,
    terrorist attack, natural disaster or other hazards to public safety
    and well-being."[^51] By the same token, the Department of Commerce,
    and more specifically NOAA Weather Radio, as the \"All Hazards\"
    radio network, acts as the source for weather and emergency
    information, including natural (such as earthquakes or avalanches),
    environmental (such as chemical releases or oil spills), and public
    safety (such as AMBER alerts or 911) warning information.[^52]

17. FEMA also played an integral role in the development of the 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. We recognize that FEMA asserted in its February 2008 comments that
    limits on its statutory authority preclude the agency from
    fulfilling the Federal aggregator/gateway functions.[^53]
    Nevertheless, timely identification of a federal agency capable of
    fulfilling the aggregator/gateway functions recommended by the
    CMSAAC is essential to bringing the concrete public safety benefits
    of a CMAS system to the American people.[^54] We are hopeful that
    any bars that prevent FEMA or some other entity within DHS from
    fulfilling these roles will be lifted expeditiously. We will work
    with our Federal partners and Congress, if necessary, to identify an
    appropriate government entity to fulfill these roles, whether that
    is FEMA, another DHS entity, NOAA or the FCC.

19. *Scope of Order.* Accordingly for purposes of this Order, we proceed
    on the assumption that a Federal agency will assume these roles at a
    future date. Today's Order is limited to adopting rules governing
    those sections of the CMAS architecture that are within the control
    of electing CMS providers.[^55] These include rules regarding the
    CMS Provider Gateway, CMS provider infrastructure, and CMS provider
    handsets. Specifically, we adopt rules, based on the 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").[^56] 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.[^57] In addition, we adopt 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.[^58]

20. We adopt 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.[^59] In addition, as explained below, we adopt
    requirements for the mobile device to ensure that people with
    disabilities are able to receive CMAS alerts.[^60] We also adopt the
    CMSAAC's recommendation that CMAS alerts not preempt ongoing voice
    or data sessions.[^61]

21. In keeping with our policy to promote technological neutrality, we
    decline to adopt rules governing the communications protocols that
    the CMS providers must employ for communications across the D or E
    interfaces as identified in the architecture.[^62] We agree with the
    CMSAAC that no specific protocols should be required for the D and E
    interface, but rather that CMS providers should be allowed to retain
    the discretion to define these protocols in conjunction with their
    overall network design and with the mobile device vendors.[^63] Both
    of these interfaces lie entirely within the control of the CMS
    providers and any implementation decisions there will have no impact
    on CMAS ability to satisfy the system requirements we set forth
    elsewhere in this Order.[^64] For example, while we do include
    requirements on the type of alert information that must cross the D
    and E interfaces to enable CMAS alerts on mobile devices, we choose
    to remain silent as to the precise communications protocol that a
    CMS provider uses to convey this information to the mobile
    device.[^65] This approach gives the CMS providers maximum
    flexibility to leverage technological innovation and implement the
    CMAS in a cost effective manner.

22. We also adopt rules requiring, per the CMSAAC's recommendation, that
    electing CMS providers assemble individual profile information to
    provide to the Authorized Federal Government Entity, once that
    entity is identified.[^66] We believe that electing CMS providers
    expect to assemble this information, and by adopting this
    requirement now, we are providing direction to potential Alert
    Gateway providers.[^67]

23. The CMSAAC recommended detailed technical protocols and
    specifications for the Alert Aggregator/Gateway entity and the CMS
    providers to employ for the delivery of alerts over the various
    interfaces (*i.e.*, A, B and C interfaces) in the Reference Model.
    Specifically, section 10 of the CMSAAC recommendations proposed
    requirements that Alert Initiators must meet to deliver CMAS alerts
    to the Alert Aggregator, and that the Alert Gateway must meet to
    deliver CMAS alerts to the CMS Provider Gateway.[^68] The CMSAAC
    also recommended CAP-based mapping parameters.

24. We support the technical protocols and specifications for the
    delivery of alerts recommended by the CMSAAC in this section.
    Electing CMS providers could use these technical protocols and
    specifications to design their internal systems that would enable
    compliance with the rules we adopt in this docket. We decline,
    however, to codify these protocols and specifications in this Order.
    We believe that these protocols offer a significant guidance to CMAS
    participants as they further develop the final protocols and
    interface for the CMAS, but until an Alert Aggregator/Gateway entity
    is determined, additional refinements and revisions of these
    protocols and specifications are inevitable. Accordingly, we
    conclude that final determination of these interface protocols is
    better left to industry standards organizations.[^69] We will
    revisit this matter in the future if Commission action in this area
    is indicated.

## General CMAS Requirements 

25. In this section, we establish the basic regulatory framework of the
    new CMAS. Specifically, we adopt technologically neutral rules that
    address, among other things, the scope of CMAS alerts, geo-targeting
    and alert accessibility for people with disabilities and the
    elderly.

### Scope and Definition of CMAS Alerts

26. The WARN Act requires the Commission to enable commercial mobile
    alerting capabilities for "emergency" alerts,[^70] but does not
    define what may comprise an emergency. Accordingly, in the *CMAS
    NPRM*, we sought comment on the appropriate scope of emergency
    alerts, including whether and to what extent alerts should be
    classified.[^71] We specifically asked parties to address whether we
    should implement the CMSAAC's recommendation to specify three alert
    classes: (1) Presidential Alert; (2) Imminent Threat Alert; and (3)
    Child Abduction Emergency or AMBER Alert.[^72] For the reasons
    stated below, we find that the public interest will be best served
    by our adopting these three alert classes, and we define them below.

27. We agree with the majority of commenters that the three classes of
    alert recommended by the CMSAAC achieves the best balance between
    warning of imminent threat to life and property with the current
    technical limits that CMS provider systems face in delivering
    timely, accurate alerts.[^73] Alert Systems however argues that we
    should include additional classes of alerts, such as traffic
    advisories.[^74] We find that inclusion of such alerts would be
    inconsistent with the intent of Congress, expressed throughout the
    WARN Act, that the Commission enable an "emergency" alerting system.
    We believe that if the public were to receive commercial mobile
    alerts that do not relate to *bona fide* emergencies, there would be
    a serious risk that the public would disregard mobile alerts or
    possibly opt not to receive anything but Presidential alerts.[^75]
    We also note that, given the current technical capabilities of CMS
    providers to deliver emergency alerts, it is possible that if too
    many alerts are injected into a CMS provider's system in a very
    brief period, vital messages could be delayed. Accordingly, we
    reject arguments to broadly define eligible alert classes beyond
    those specified here.

#### Presidential Alerts 

28. Section 602(b)(2)(E) of the WARN Act authorizes participating CMS
    providers to allow device users to prevent the receipt of alerts or
    classes of alerts "other than an alert issued by the
    President."[^76] Congress thus intended to afford Presidential
    Alerts the highest priority. Affording Presidential Alerts the
    highest priority also will enable the Secretary of Homeland Security
    to meet his/her obligation, under Executive Order 13407, to "ensure
    that under all conditions the President of the United States can
    alert and warn the American people."[^77] Accordingly, electing CMS
    providers must transmit such alerts and assign the highest priority
    to any alert issued by the President or the President's authorized
    designee.[^78] Further, Presidential Alerts must be transmitted upon
    receipt by a CMS provider, without any delay, and therefore will
    preempt any other pending alert. We note that due to the initial
    90-character text message protocol that we are adopting below for
    the first generation CMAS,[^79] it is possible that a Presidential
    Alert may direct recipients to other sources, possibly taking the
    form recommended by the CMSAAC: "The President has issued an
    Emergency Alert. Check local media for more details."[^80]

#### Imminent Threat Alerts

29. We note that virtually all commenting parties support adoption of
    the CMSAAC's recommendation to define an Imminent Threat Alert
    class.[^81] This alert class is narrowly tailored to those
    emergencies where life or property is at risk, the event is likely
    to occur, and some responsive action should be taken. Specifically,
    an Imminent Threat Alert must meet separate thresholds regarding
    urgency, severity, and certainty. Each threshold has two permissible
    CAP values.

-   Urgency. The CAP "urgency" element must be either Immediate (*i.e.*,
    responsive action should be taken immediately) or Expected (*i.e.*,
    responsive action should be taken soon, within the next hour).[^82]

-   Severity. The CAP "severity" element must be either Extreme (*i.e.*,
    an extraordinary threat to life or property) or Severe (*i.e.*, a
    significant threat to life or property).[^83]

-   Certainty. The CAP "certainty" element must be either Observed
    (*i.e.*, determined to have occurred or to be ongoing) or Likely
    (*i.e.*, has a probability of greater than fifty percent).[^84] That
    is, the event must have occurred, or be occurring (Observed), or be
    more likely to occur than not (Likely).

30. We find that the transmission of these imminent threat alerts is
    essential to a useful CMAS. The CMSAAC recommended such action and
    the commenting parties overwhelmingly support this conclusion.[^85]
    As T-Mobile correctly states, CMAS alerts are not appropriate for
    warning the public about minor events.[^86] Subscribers are more
    likely to opt out if they are bombarded by minor notices, and may
    fail to notice a truly serious alert. Also, inclusion of minor
    events would be an unnecessary burden on the CMS provider
    infrastructure. Accordingly, we find it appropriate to require
    participating CMS providers to transmit Imminent Threat Alerts.

#### Child Abduction Emergency/AMBER Alerts

31. 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.[^87] There are four types of AMBER
    Alerts: (1) Family Abduction,[^88] (2) Nonfamily Abduction,[^89] (3)
    Lost, Injured, or Otherwise Missing,[^90] and Endangered
    Runaway.[^91] AMBER plans are voluntary partnerships between law
    enforcement agencies, broadcasters and CMS providers to activate an
    urgent bulletin in the most serious child abduction cases, and AMBER
    alerts are issued only where an AMBER plan has been duly
    established.[^92] We also note that a number of CMS providers
    currently transmit AMBER Alerts using Short Message Service (SMS)
    technology,[^93] and we applaud their potentially life-saving
    efforts in this regard.

32. In 2006, 261 AMBER Alerts were issued in the United States involving
    316 children.[^94] Most of these alerts were issued on an intrastate
    basis.[^95] Of the 261 AMBER Alerts issued in 2006, 214 cases
    resulted in a recovery, 53 of which were resolved as a direct result
    of an AMBER Alert being issued.[^96] Based on the limited number of
    AMBER alerts and their confined geographic scope, we do not expect
    such alerts to be overly burdensome to CMS providers that
    participate in the CMAS. Moreover, because of the efficacy of AMBER
    Alerts, we find that the public interest in the safety of America's
    children will be well served by the provision of AMBER Alerts by the
    wireless industry. Accordingly, we require participating CMS
    providers to transmit AMBER alerts.

### Technologically Neutral Alert System 

33. The CMSAAC recommended that CMS providers that elect to participate
    in the CMAS should "not be bound to use any specific vendor,
    technology, software, implementation, client, device, or third party
    agent, in order to meet \[their\] obligations under the WARN
    Act."[^97] We agree. As SouthernLINC notes, participating CMS
    providers should be able to choose the technology that will allow
    them to best meet the emergency alerting needs of the American
    public.[^98] Consistent with the Commission's well-established
    policy of technologically-neutral regulation of the wireless
    telecommunications industry,[^99] we believe that CMS providers and
    equipment manufacturers are in the best position to select and
    incorporate the technologies that will enable them to most
    effectively and efficiently deliver mobile alerts. Accordingly, we
    will not limit the range of technologies that electing CMS providers
    may deploy to participate in the CMAS. In reaching this conclusion,
    we have balanced the alerting needs of the public and the
    capabilities of electing CMS providers and our mandate under section
    602(a) of the WARN Act to enable the provision of emergency
    alerts.[^100] We emphasize that the WARN Act does not require the
    establishment of any specific technology to be used for the CMAS.

34. CMS providers are in various stages of readiness to participate in
    the CMAS. Paging carriers already provide point to multipoint
    services, using technologies such as ReFLEX and POCSAG (Post Office
    Code Standardization Advisory Group), to reach many subscribers at
    the same time and therefore appear well-positioned to participate in
    CMAS.[^101] However, as the American Association of Paging Carriers
    notes, it may not be feasible for paging carriers to confine their
    alerts to either county-wide or sub-county distribution.[^102]
    Further, cellular, PCS, and SMR service providers, report that they
    have not deployed an emergency alerting capability that satisfies
    all requirements in the CMSAAC recommendations and that is currently
    available for the mass transmission of alerts.[^103] We note that
    many of the requirements that we adopt today are intended to apply
    to a first generation text-based alerting service. Other service
    profiles, such as streaming audio and video, are in their early
    developmental stages and thus not ripe for implementation by the
    Commission. We foresee that as CMS providers gain experience with
    these and other alerting technologies, they may well be incorporated
    into future alerting system deployments.

35. Although the CMSAAC found that point-to-point technologies may not
    be well suited for mass alerting,[^104] we will not prohibit their
    use if a CMS provider can otherwise meet the requirements that we
    establish today. Short Message Service (SMS)[^105] text messaging is
    available to most cellular, PCS, and SMR subscribers and is
    currently used by some municipalities and other local jurisdictions
    to provide emergency alerts on an opt-in basis.[^106] We recognize,
    however, that SMS may not be a desirable solution for the widespread
    dissemination of alerts to the public because the mass delivery of
    SMS-formatted alerts could degrade network performance and delay
    alert delivery. Despite these potential drawbacks, SMS text
    messaging may offer a viable, short-term delivery method for
    electing CMS providers that do not yet have a point-to-multipoint
    text messaging capability.[^107]

36. The CMSAAC noted that technologies such as MediaFLO and DVB-H "may
    provide supplemental alert information,"[^108] but recommended that
    they should not be considered as part of the CMAS.[^109] Our goal in
    this proceeding is to enable the broadest possible voluntary
    participation in the CMAS, and we will not foreclose the possible
    deployment of these or other innovative technologies as a means of
    participating in the nascent CMAS. The public interest is best
    served by not circumscribing the range of technologies that CMS
    providers may elect to deploy to meet the alerting needs of the
    American public.

37. Several parties express support for an FM-based CMAS solution such
    as that provided by ALERT-FM and Global Security Systems.[^110] The
    CMSAAC however considered the costs and benefits of Radio Broadcast
    Data System (RBDS) and other FM-based alert and warning solutions,
    and found them to be infeasible for the CMAS. [^111] Moreover, a
    number of parties have expressed reservations about these
    technologies.[^112] Nonetheless, in keeping with our overall policy
    to maintain technological neutrality, we do not require or prohibit
    the use of ALERT-FM, RBDS or similar systems as the basis of the
    CMAS.[^113]

38. We also strongly encourage fair, reasonable, and nondiscriminatory
    Intellectual Property Rights (IPR) licensing in the context of the
    CMAS. We agree with the CMSAAC that the technical standards,
    protocols, procedures, and related requirements that we adopt
    pursuant to section 602(a) of the WARN Act today should be
    standardized in industry bodies that have well defined IPR
    policies.[^114] We decline, however, to compel all CMSAAC
    participants "to provide written assurance to the Commission that,
    if and insofar as one or more licenses may be required under any of
    their respective IPRs that are technically essential for purposes of
    implementing or deploying CMAS, the rights holders shall license
    such IPR on a fair, reasonable and nondiscriminatory basis for those
    limited purposes only."[^115] We also decline to require "all
    participants in the public comment process on th\[e\] CMAS
    Architecture and Requirements document" to make such a written
    assurance.[^116] These requests are outside the scope of section
    602(a) of the WARN Act.

39. The CMSAAC made a number of additional recommendations that we
    conclude are outside the scope of our mandate under section 602(a)
    of the WARN Act to adopt "technical standards, protocols,
    procedures, and other technical requirements," to enable voluntary
    commercial mobile alerting.[^117] Specifically, the CMSAAC submitted
    recommendations regarding the applicability of requirements for
    location, number portability and the Communications Assistance for
    Law Enforcement Act (CALEA).[^118] The CMSAAC also submitted
    recommendations on whether CMS providers may utilize the technical
    requirements adopted herein for other services and purposes and
    whether CMS providers may recover certain costs related to the
    development of the CMAS.[^119] We find that these issues are outside
    the scope of section 602(a) of the WARN Act and, therefore, do not
    address these issues herein.

40. The CMSAAC recommended that, to the extent practicable, "Federal,
    state, tribal, and local level CMAS alert messages \[should\] be
    supported using the same CMAS solution."[^120] We agree. We believe
    that a uniform approach to implementation of the CMAS will be
    inherently more cost effective, more technologically consistent and
    thus more likely to facilitate participation by small and rural CMS
    providers. Further, we agree that electing CMS providers should not
    be required to support alerting on mobile handsets manufactured for
    sale to the public prior to a CMS provider's initiation of the CMAS
    alerting service. In a subsequent order, we will address how
    participating CMS providers may sell such non-compliant handsets
    consistent with the requirement under section 602(b) of the WARN Act
    that they disclose "at the point of sale of any devices with which
    its commercial mobile service is included, that it will not transmit
    such alerts via the service it provides for the device."[^121]
    Finally, we agree that electing CMS providers should have discretion
    regarding whether certain devices, such as laptop wireless data
    cards, will support alerting capabilities.

### CMAS Message Elements and Capabilities

#### Required Alert Message Elements

41. The CMSAAC recommended that emergency alert messages follow the same
    general format of National Weather Service alert messages, subject
    to a 90-character text limitation.[^122] Specifically, the CMSAAC
    recommended that for initial CMAS deployments, messages should
    include five elements in the following order:

-   Event Type or Category

-   Area Affected

-   Recommended Action

-   Expiration Time (with time zone)

-   Sending Agency

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

42. There is broad support in the record for standardization of alert
    messages and adoption of the five recommended message elements.
    T-Mobile explains that the format "is designed to ensure that the
    most critical information is succinctly and clearly communicated in
    a manner most compatible with the technical attributes of wireless
    networks."[^126] Purple Tree Technologies also supports the five
    message elements, but urges that event type and area affected be the
    only required elements, with others optional if space permits.[^127]
    Based on our review of the record, we find that on balance the five
    message elements identified above will enable standardization of
    alerting messages and we hereby adopt them. We reject Alert Systems'
    claim that the element for "area affected" should be reconsidered,
    based on its hypothesis that "visitors and newcomers to areas often
    do not recognize geographic landmarks in warning messages."[^128] A
    biohazard or flash flood warning, for example, would not enable the
    public to avoid a lethal hazard without appropriate area affected
    information. We also expect that as CMAS providers eventually deploy
    technologies capable of messages of more than 90 characters,
    additional alert message elements will be implemented.

43. In the *CMAS NPRM*, we also sought comment on whether alert messages
    should include telephone numbers, URLs[^129] or other response and
    contact information, including any related network impacts.[^130]
    The CMSAAC advised against inclusion of URLs or telephone numbers
    because such information would encourage mass access of wireless
    networks.[^131] The California Public Utility Commission (CAPUC)
    supports inclusion of a sixth message element for URLs, if
    feasible.[^132] AT&T (and many commenting parties) note that
    inclusion of a URL or telephone number in an emergency message, some
    of which might be delivered to tens of thousands of users in a
    matter of seconds, could lead to unacceptable network congestion
    and, in extreme cases, network failure.[^133] We find that mandating
    URLs or telephone numbers in an emergency alert could exacerbate
    wireless network congestion at a time when network traffic is
    already dramatically increasing as individuals contact police, fire,
    and rescue personnel, as well as their loved ones.[^134] We
    therefore will not require participating CMS providers to accept or
    transmit any alert message that contains an embedded URL or
    telephone number.

#### CMAS Generation of Free Text Alert Messages

44. In the *CMAS NPRM*, we 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.[^135] The CMSAAC
    recommended this approach for initial system deployments.[^136] We
    also sought comment on the CMSAAC's recommendation to allow the
    generation of free text for Presidential and AMBER alert
    messages.[^137] While numerous parties in this proceeding support
    adoption of the CMSAAC recommendations in full, few address the
    specific mechanics of generating alert messages via the Alert
    Gateway.[^138] AT&T states that proposals for automatic generation
    of alert text "merit further investigation, but responsibility for
    the content of alerts should remain with initiators and the federal
    government---not wireless carriers."[^139] We agree with AT&T and
    other parties that electing CMS providers should act as a conduit
    for messages, the content of which is fixed before transmission to a
    CMS provider.

45. CellCast argues that we should "ignore" the CMSAAC recommendations
    regarding alert generation, asserting that message generation is
    beyond our mandate under the WARN Act.[^140] The mechanisms for
    generating messages at the Alert Gateway are undefined currently and
    may be subject to implementation by the federal entity selected to
    administer the Alert Gateway. Nonetheless, we support the CMSAAC's
    recommended approach of allowing the Alert Gateway to create
    messages using CAP fields and SAME codes.[^141] Specifically, we
    believe that this approach would enable the provision of consistent
    and accurate messages to the public, while facilitating future
    enhancements to the Alert Gateway.

46. We also agree with the CMSAAC that automatic generation of messages
    via CAP fields and SAME codes may not always provide sufficient
    flexibility to alert initiators to tailor messages for emergencies
    that may fall with the Imminent Threat Alert category.[^142] A
    message with a translated event code of "security warning," for
    example, may not provide adequate information about a shooting
    incident on a college campus. A more apt warning might be "a
    shooting has occurred on the north campus," with directions to "stay
    indoors." We thus believe that the public interest would be served
    if the CMAS architecture accommodates free-form text messaging,
    subject to the 90-character text limit that we adopt today and our
    determination that electing CMS providers will generally not be
    obligated to accept or transmit any alert message that includes an
    embedded URL or phone number.[^143] We also agree with the CMSAAC
    that free-form text should be included as a CAP message
    parameter.[^144]

47. Finally, we concur with the CMSAAC that automatic text generation at
    the Alert Gateway would be impractical for Presidential or AMBER
    Alerts,[^145] both of which are likely to be highly fact specific.
    As the CMSAAC noted, the efficacy of a particular AMBER Alert hinges
    on specific information such as a description of a vehicle,
    abductor, or missing child.[^146] Accordingly, we find that law
    enforcement authorities should have the ability to formulate unique
    message text for the dissemination of AMBER Alerts via the CMAS. We
    envision that such free text messages would be presented to the
    Alert Gateway in a free text CAP field. In the event of a
    Presidential Alert, we agree with the CMSSAC that, until such time
    as electing CMS providers are able to transmit messages longer than
    90 characters, the Alert Gateway may employ a generic statement such
    as "The President has issued an emergency alert. Check local media
    for more details."[^147]

### Geo-targeting CMAS Alerts

48. The CMSAAC recommended that "to expedite initial deployments of CMAS
    an alert that is specified by a geocode, circle or polygon" should
    "be transmitted to an area not larger than the CMS \[provider's\]
    approximation of coverage for the county or counties with which that
    geocode, circle, or polygon intersects."[^148] Based on the
    substantial record before us and for the reasons stated below, we
    require electing CMS providers to geographically target (geo-target)
    alerts accordingly. We note that radio frequency (RF) propagation
    areas for some paging systems and cell sites may exceed a single
    county, and we will permit geo-targeting that exceeds county
    boundaries in these limited circumstances.

49. Congress recognized the importance of geo-targeting alerts in the
    WARN Act. Specifically, in section 604 of the WARN Act, Congress
    directed the Under Secretary of Homeland Security for Science and
    Technology, in consultation with the National Institute of Standards
    and Technology (NIST) and the FCC, to establish a research program
    for "developing innovative technologies that will transmit
    geographically targeted emergency alerts to the public."[^149] The
    Commission stands ready to work with DHS and NIST to facilitate this
    important undertaking.[^150] We fully expect that as more refined
    and cost effective geo-targeting capabilities become available to
    electing CMS providers, they will voluntarily elect to target alerts
    more granularly. Several CMS providers have indicated their
    intention to geo-target alerts below the county level and we
    strongly encourage them to do so.[^151] As T-Mobile notes, electing
    CMS providers should be free to target more specifically, subject to
    the liability protections of the WARN Act.[^152]

50. In the *CMAS NPRM*, we sought comment on what level of precision the
    Commission should require for geo-targeting,[^153] considering the
    CMSAAC's recommendation for county-level geo-targeting.[^154] The
    CMSAAC recognized "that it is the goal of the CMAS for CMS providers
    to be able to deliver geo-targeted alerts to the areas specified by
    the Alert Initiator."[^155] 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."[^156] The CMSAAC
    recommended that providers should be allowed (but not required) to
    deliver alerts to areas smaller than a county, using Geographic
    Names Identification System (GNIS) codes, polygon, or circle
    information to identify a predefined list of cell sites/paging
    transceivers within the alert area.[^157]

51. Several parties however urge us to mandate sub-county targeting.
    Alert Systems claims that disaster managers often require greater
    geographic granularity than that permitted by CAP and the CMSAAC
    recommendations.[^158] Purple Tree Technologies asserts that
    sub-county targeting is "possible with cell broadcast," and that
    there are few technical hurdles preventing granular alerts.[^159]
    Acision and CellCast both contend that cell broadcast technology
    would allow for targeting to the individual cell level.[^160] DataFM
    claims its technology could target "specific geographic areas
    without regard to the location of its transmitters."[^161]

52. The National Emergency Number Association (NENA) favors targeting
    smaller areas, noting that some counties are very large and that
    alert originators often need to target precisely.[^162] NENA asserts
    that targeting messages to the block level (similar to emergency
    telephone notification systems) would be "ideal," but recognizes
    this is not possible.[^163] The CAPUC argues that county targeting
    would be overbroad for most emergencies, and urges ZIP-code level
    targeting.[^164] We note that there are more than 40,000 active ZIP
    codes in the United States, and many of these are assigned to
    specific addresses.[^165] The CAPUC does not explain how ZIP code
    targeting could be implemented.[^166]

53. The weight of the record supports county-level targeting as
    recommended by the CMSAAC. CTIA, TIA and 3G Americas urge us to
    implement county-level targeting, with optional granularity, to
    encourage expeditious deployment of alerting capabilities.[^167]
    T-Mobile agrees that electing CMS providers should not be not
    required to target alerts to areas smaller than a county, noting
    that given current technological limitations, many carriers would be
    unable to achieve more specificity.[^168] Alltel also supports
    county-level targeting, but states that it intends to target more
    granularly.[^169]

54. MetroPCS notes that for smaller targeting areas, electing CMS
    providers would have to more precisely control the delivery of
    messages by the base stations serving a given targeted area than is
    currently economically feasible.[^170] Similarly, The National
    Telecommunications Cooperative Association (NTCA) states that
    requiring electing rural CMS providers to send alerts to sub-county
    areas may be too expensive and may reduce the incentive to
    participate in the CMAS.[^171] The American Association of Paging
    Carriers (AAPC) opposes county-level targeting, noting that it may
    not be feasible for some paging providers to confine alerts to the
    county level, and that they would target alerts to the extent
    permitted by their networks.[^172]

55. Based on the foregoing, and subject to the limited exception
    discussed below, we conclude that it would be premature for us
    generally to require targeting of alerts more precisely than the
    county level. We specifically note that county-level targeting is
    consistent with the current practices of the National Weather
    Service, which is expected to originate many CMAS alerts. While some
    commenters argue that cell broadcast and perhaps other technologies
    could support more granular targeting,[^173] the record indicates
    that not all CMS providers may employ cell broadcasting for their
    delivery of CMAS. Further, while several vendors urge us to mandate
    sub-county targeting,[^174] at this point we find that the public
    interest is best served by enabling participating CMS providers to
    determine which technologies will most efficiently and cost
    effectively allow them to target alerts more precisely than the
    county level.

56. Accordingly, we generally require CMS providers that elect to
    participate in the CMAS to geographically target emergency alerts to
    the county level. In adopting this rule, we recognize the concerns
    of many CMS providers that face technical limitations on their
    ability to geo-target alerts to areas smaller than a county. In
    those limited circumstances where the propagation area of a paging
    system or cell site exceeds a single county, we will permit the RF
    signal carrying the alert to extend beyond a 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,[^175]
    we will address this recommendation once an entity has been
    identified to provide the Alert Aggregator and Gateway functions.

### Meeting the Needs of Users, Including Individuals with Disabilities and the Elderly 

57. Section 603(b)(3)(F) of the WARN Act required that the CMSAAC
    include representatives of national organizations representing
    people with special needs, including individuals with disabilities
    and the elderly.[^176] Because the WARN Act directed the CMSAAC to
    submit recommendations to the Commission "as otherwise necessary to
    enable electing CMS providers to transmit emergency alerts to
    subscribers,"[^177] the CMSAAC concluded, and we agree, that
    Congress intended to include the elderly and those with disabilities
    among the class to which electing CMS providers are to deliver
    alerts. Accordingly, we conclude that CMAS access to those with
    disabilities and the elderly falls within our obligation under
    section 602(a) of the WARN Act, and thus seek to ensure that
    commercial mobile alerts are accessible to all Americans, including
    individuals with disabilities and the elderly.

58. The CMSAAC recommended that the needs of individuals with
    disabilities and the elderly be addressed by, *inter alia*, the
    inclusion of a common audio attention signal, and a common vibration
    cadence, on devices to be used for commercial mobile alerts.[^178]
    The CMSAAC recommended that both functions be distinct from any
    other device alerts and restricted to use for commercial mobile
    alerting purposes. [^179] The CMSAAC further noted that these
    features would benefit not only individuals with disabilities and
    the elderly, but also subscribers more generally.

59. For devices with polyphonic capabilities, the CMSAAC recommended
    that the audio attention signal should consist of more than one
    tone, in a frequency range below 2 kHz and preferably below 1 kHz,
    combined with an on-off pattern to make it easier for individuals
    with hearing loss to detect.[^180] For devices with only a single
    frequency capability, the CMSAAC recommended an audio attention
    signal below 2 kHz.[^181] The CMSAAC also recommended that the
    unique vibration cadence should be noticeably different from the
    default cadence of the handset.[^182] The CMSAAC further recommended
    that if a device includes both the audio and vibration functions,
    simultaneous activation of both functions should not be required and
    that configuration should be determined by end users.[^183]

60. In the *CMAS NPRM*, we sought comment on the CMSAAC recommendations,
    including any technical or accessibility requirements that we should
    adopt to ensure that commercial mobile alerts will be received by
    individuals with disabilities and the elderly.[^184] We asked
    whether attention signals should be required for all users.[^185] We
    also noted that the CMSAAC recommended that alert initiators use
    clear and simple language whenever possible, with a minimal use of
    abbreviations and the ability to recall alert messages for
    review---and sought comment on these recommendations within the
    context of accessibility for individuals with disabilities and the
    elderly.[^186]

61. Nearly all commenting parties support the 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.[^187] Alert Systems likewise notes that "\[u\]rgency coding
    of messages is vital,"[^188] and that caretakers and operators of
    certain industrial facilities in particular "need unique alert tone
    patterns/amplitudes to quickly reprioritize activities."[^189]

62. The Wireless Rehabilitation Engineering Research Center for Wireless
    Technologies (Wireless RERC) supports adoption of a common audio
    attention signal, and recommends that we adopt the existing 8-second
    EAS attention signal for all users, asserting that it provides the
    necessary period of time to alert individuals with hearing
    disabilities.[^190] The Wireless RERC also supports adoption of a
    common vibration cadence, and states that electing CMS providers
    should provide clear instructions on the alert capabilities of their
    devices, including labels identifying mobile devices suitable for
    persons with audio and visual disabilities.[^191] AAPC supports the
    CMSAAC recommendations, but states that legacy devices should not be
    required to support such functions.[^192] CAPUC adds that although
    the CMSAAC was required to issue recommendations on wireless alerts
    exclusively, the Commission should consider ensuring
    interoperability with wireline devices for individuals with
    disabilities and the elderly, noting that some such users may not
    have access to wireless devices.[^193] DataFM notes that it
    currently has equipment for text-to-speech for the blind and strobe
    light warnings for the deaf, and would employ audio alerts and
    vibration alerts for portable devices.[^194]

63. Although there is near unanimous support of the 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.[^195] CellCast argues that no changes to CMS provider
    networks should be required, noting that some mobile devices can be
    configured to enable the elderly or blind to hear an audio
    conversion of the message using text-to-speech technologies.[^196]

64. We agree with the majority of those commenting and the CMSAAC that
    it is vital that we ensure access to commercial mobile alerts by
    individuals with disabilities and the elderly. We disagree with the
    premise articulated by some commenters that merely because some
    device manufacturers already include accessibility features for
    receipt of mobile alerts, no requirements are needed to ensure
    access to mobile alerts for individuals with disabilities and the
    elderly.

65. Accordingly, to address the needs of these user groups and the needs
    of users more generally, we will require that participating CMS
    providers include both a common vibration cadence and a common audio
    attention signal on any device offered to the public for reception
    of commercial mobile alerts.[^197] Specifically, as the CMSAAC
    recommended, we specify a temporal pattern for the audio attention
    signal of one long tone of two (2) seconds, followed by two short
    tones of one (1) second each, with a half (0.5) second interval
    between the tones.[^198] We will also require that the entire
    sequence be repeated twice with a half (0.5) second interval between
    repetitions.[^199] For devices with polyphonic capabilities, we
    adopt the 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, we will require that a universal audio
    attention signal be of 960 Hz (the higher frequency EAS tone).

66. We also seek to facilitate recognition of alerts for individuals
    that may have a hearing disability (or who may have muted the audio
    attention signal on their device), and therefore adopt the same
    temporal pattern for the vibration cadence as the CMSAAC recommended
    that the Commission specify for the audio attention signal. We
    strongly encourage CMS providers to coordinate with device
    manufacturers to utilize existing technologies to comply with these
    requirements as soon as possible.

67. We recognize that incorporating capabilities for a common audio
    attention signal and a common vibration cadence on the many devices
    that we expect to be offered to the public will take time to develop
    and implement successfully. However, we believe that assuring full
    access for all Americans is sufficiently important that equipment
    may not be considered CMAS compliant unless it includes both the
    common audio attention signal and the vibration cadence adopted in
    this Report and Order. Further, both functions must be distinct from
    any other incoming message alerts and restricted to use for CMAS
    alerting purposes. Finally, simultaneous activation of both the
    audio attention signal and vibration cadence is permissible.[^200]

### Output Mode/Display

68. The CMSAAC issued several recommendations regarding the output
    mode/display of mobile devices.[^201] Specifically, the CMSAAC
    recommended that CMAS-enabled mobile devices should employ display
    fonts that are easily readable with recognizable characters, citing
    three typeface examples.[^202] MetroPCS notes that certain
    accessibility requirements already apply to CMS providers, and that
    CMAS-enabled mobile devices will therefore accommodate certain
    disabilities.[^203] CellCast adds that the development of mobile
    devices is highly competitive and flexible enough to meet the needs
    of all users including those with special needs.[^204] Although we
    agree with the CMSAAC that "the goal in font selection is to use
    easily recognizable characters,"[^205] we do not want to constrain
    the ability of CMS providers and manufacturers of devices to
    implement display modes that they find will best meet the needs of
    people with disabilities and other users. Accordingly, we do not
    limit the display of CMAS alerts to a particular font or character
    set.

69. Text-to-speech (TTS) enabled wireless mobile devices are becoming
    increasingly common,[^206] and we strongly encourage all
    participating CMS providers to offer devices with such capabilities
    so that blind individuals and those with severe visual impairments
    can obtain the public safety benefits of commercial mobile alerts.
    We note that many of the requirements that we adopt today for the
    first generation of CMAS are intended to enable the provision of
    text-based alerts to the public. Although we envision that the CMAS
    will evolve to include audio and video service profiles, we find
    that at this initial stage of the CMAS, it would be premature to
    address the CMSAAC's recommendations regarding output mode/displays
    for such future service profiles.

### Message Retransmission

70. We agree with the CMSAAC that alerts should be retransmitted
    periodically to an affected area until their specified
    expiration.[^207] Periodic retransmission of alerts is vital because
    some individuals, particularly motorists, may enter an alert area
    after initial transmission of an alert. Others may miss the initial
    alert because of an ongoing call (as explained below, alerts may not
    preempt a call in progress),[^208] or because they had their mobile
    device turned off or muted when an alert was first transmitted. As
    the CMSAAC noted, the optimal frequency of alert retransmission
    requires a balancing of many factors, including the capabilities of
    a CMS 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.[^209] We agree with this
    assessment and adopt this recommendation as reasonable for the
    initial implementation of the CMAS. As the system is deployed, we
    may wish to revisit the issue to see if a consistent, industry-wide
    alert retransmission interval would be more appropriate.

### Multi-Language CMAS Alerting 

71. The WARN Act required the CMSAAC to submit recommendations to the
    Commission regarding "the technical capability to transmit emergency
    alerts by electing commercial mobile providers to subscribers in
    languages in addition to English, to the extent practical and
    feasible."[^210] In the *CMAS NPRM*, we sought comment on the
    technical feasibility of providing commercial mobile alerts in
    languages in addition to English,[^211] including how the provision
    of alerts in multiple languages could affect the generation and
    distribution of messages on a local, state, and national
    level.[^212] Based on the record before us, we find that it would be
    premature to require CMS providers to transmit alerts in languages
    in addition to English. As explained below, we agree with the CMSAAC
    and those commenters that state that further technical study is
    needed to enable the provision of alerts in multiple languages.

72. The CMSAAC provided recommendations regarding multi-language
    alerting in section 5.7 of its report. The CMSAAC specifically
    "recognized that there is a strong desire for the CMAS to support
    Spanish in addition to English," but found that supporting multiple
    languages in the first generation of CMAS could adversely impact
    system capacity and increase message latency.[^213] It noted that
    while Spanish and English would cover 99 percent of all U.S.
    households, there are more than 37 languages in the United States
    that exceed 1 percent of households on a local level. [^214] The
    CMSAAC stated that delivering CMAS alerts in these languages would
    require mobile devices capable of supporting at least 16 different
    character sets.[^215] The CMSAAC also stated that some languages
    require two bytes per character rather than one byte per character
    for English, thereby further limiting message length.[^216] The
    CMSAAC found that the technical feasibility of providing alerts in
    languages in addition to English is a highly complex issue requiring
    further study. Finally, the CMSAAC noted that the CMAS architecture
    can support language extensions and recommended that this capability
    be reserved for future study.[^217]

73. Several parties disagree that the technical feasibility of providing
    alerts in languages in addition to English requires further study,
    and urge us to mandate the provision of alerts in multiple languages
    now. The CAPUC notes that "roughly 30.1 percent of California's
    population has limited English proficiency,"[^218] and that the
    State "uses different languages for different types of
    communications . . . \[including\] Spanish, Cantonese, Mandarin,
    Tagalog, Vietnamese, Korean, Farsi, Arabic, and Hmong."[^219] The
    CAPUC asserts "that various commercial alert service providers
    represent that they can provide alerts in six different
    languages,"[^220] but does not identify these service providers.
    There is no evidence in the record before us however of any CMS
    provider having the current capability to deliver alerts in six
    different languages, and we therefore cannot adopt CAPUC's request
    that we require transmission of alerts in a minimum of six
    languages.[^221]

74. CellCast and One2many also urge us to implement multiple language
    alerting. CellCast notes that pending standards under the ITU for
    Message Indicators (MIs) can facilitate either the dedication of
    discrete MIs for specific languages, or the rejection of messages in
    undesired languages via the message preamble.[^222] CellCast
    suggests that such standards would provide clear direction for
    international harmonization of emergency alerting systems and
    handsets.[^223] CellCast further argues that the potential latency
    of multiple messages in sequential languages would be indiscernible
    to a mobile user and should not impact that user's ability to react
    to an emergency.[^224] CellCast claims that the delivery of
    multi-language alerts would not add any new burden on the Alert
    Aggregator or the CMS provider, and would not require any
    development of new technology.[^225] One2many states that there are
    numerous "channels," or Message Identifiers, available in a cell
    broadcast.[^226] According to One2many, end users can activate their
    phones to receive messages on the channel number that matches their
    language.[^227]

75. By contrast, most parties in this proceeding concur with the CMSAAC
    that further study of multiple language alerting is necessary. CTIA,
    for example, states that we should not require electing CMS
    providers to transmit alerts in multiple languages because of
    limitations in providers' existing air interfaces, handset character
    sets, and traffic overflow.[^228] Regarding the varying air
    interfaces, Alltel concurs with the CMSAAC that transmitting
    multi-language alerts is not technically feasible for CDMA systems,
    subject to future review as technology improves.[^229] According to
    Alltel, GSM can support multiple channels for simultaneous broadcast
    and discrete channels could be dedicated to different
    languages.[^230] Alltel explains that CDMA lacks this capability and
    would require sequential broadcasts of alerts in multiple languages
    with the potential for unacceptable latency between broadcasts of
    the same language while alerts in multiple languages are
    sequentially broadcast.[^231]

76. With respect to character set limitations in mobile devices,
    MetroPCS states that most handsets currently marketed in the United
    States use the Latin alphabet and would not support other
    languages---and that adding such capabilities would create
    substantial burdens on electing CMS providers and manufacturers,
    while increasing the costs of handsets to consumers.[^232] The
    American Association of Paging Carriers similarly explains that
    parallel alerts in languages other than English would threaten
    network congestion, and complicate subscriber device designs and
    capabilities.[^233] T-Mobile adds that a multi-language requirement
    would impede CMAS deployment, and that until the technology improves
    to facilitate multiple languages, non-English speaking users could
    be prompted by an English alert to turn to sources in their
    respective languages for further information.[^234]

77. Several parties, including AT&T, recommend that the Commission
    initially require alerts only in English, but also develop a
    national plan that provides federal, state, and local alert
    initiators with clear guidance on how alert initiators must craft
    multi-language alerts that reach the electing CMS Provider Gateways
    in a standardized format ready for end-user delivery without
    translation.[^235] The CAPUC, which advocates mandatory
    multi-language alerting, urges the Commission to examine whether
    latency or delivery concerns could be resolved if language receipt
    were part of a pre-subscription process.[^236] The Wireless RERC
    asks that we encourage providers serving non-English speaking users
    to install software that will automatically translate English
    emergency messages into other languages, especially given the
    potential delay caused by an alert originator having to send out
    messages in multiple languages.[^237] These parties' insightful
    comments as well as those discussed above underscore that electing
    CMS providers face many technical challenges as they seek to
    implement alerting in languages in addition to English. Accordingly,
    we conclude that further study is needed to develop capabilities for
    providing alerts in multiple languages, and do not require provision
    of alerts in any language other than English at this time. We
    encourage the wireless industry and the public safety community to
    expeditiously develop and implement capabilities to deliver alerts
    in languages in addition to English.

### Roaming 

78. We agree with the CMSAAC and the majority of commenting parties that
    the public interest will be served by requiring participating CMS
    providers to support CMAS alerting when subscribers are receiving
    services through roaming.[^238] As discussed further below, we find
    that adopting such a requirement is consistent with our
    responsibility under the WARN Act to enable commercial mobile
    service alerting,[^239] as well as our duty under Executive Order
    13407 to "adopt rules to ensure that communications systems have the
    capacity to transmit alerts and warnings to the public as part of
    the public alert and warning system."[^240]

79. In the *Automatic Roaming Order*, the Commission found that
    "consumers have come to expect seamless wireless service wherever
    they travel within the United States and, ultimately, this will be
    achieved through automatic roaming."[^241] Thus, as a general
    matter, mobile device users will anticipate that the alerting
    features and services available to them in their home market will be
    available when roaming. Under the rules we adopt today, when a
    subscriber receives services pursuant to a roaming agreement and the
    operator of the roamed upon network is a participating CMS provider,
    the subscriber will receive alerts messages, provided the
    subscriber's mobile device is configured for and technically capable
    of receiving alert messages from the roamed upon network.[^242]

### Preemption of Calls in Progress

80. The CMSAAC recommended that CMAS alerts not preempt ongoing voice or
    data sessions.[^243] We agree with this recommendation. We believe
    that it would be contrary to the public interest if alert messages
    were to preempt certain active voice or data sessions. During a
    crisis, such as a terrorist attack, many individuals will be seeking
    emergency aid related to the actual event and other emergencies. In
    either circumstance, the public would be ill served if their calls
    for urgent aid were summarily preempted. In light of this, we will
    require that any device marketed as "CMAS compliant" must not permit
    an alert to preempt an ongoing call.

## Service Profiles 

81. In its recommendations, the CMSAAC introduced the concept of
    technology-neutral service profiles for emergency alerts, each
    containing, for example, information on maximum payload and
    displayable message size.[^244] The CMSAAC further recommended
    specific service profiles for: (a) Text; (b) Streaming Audio (future
    capability); (c) Streaming Video (future capability); and (c)
    Downloaded Multimedia Profile (future capability), and provided
    general recommendations and conclusions for each. In the *CMAS
    NPRM*, we sought comment on the service profiles recommended by the
    CMSAAC. We agree with those commenters who argue that we should
    adopt the CMSAAC's recommendation that text-only alerts are
    appropriate for an initial system.[^245] Because we believe that it
    would be premature and not consistent with our obligations under
    section 602(a) of the WARN Act to adopt standards and requirements
    for technologies that are still under development, this order will
    not address future technologies such as streaming audio, video and
    downloadable multimedia. Rather, this order will only address CMSAAC
    recommended profiles for text.

82. As part of the text profile, the CMSAAC recommended a maximum
    displayable message size of 90 characters. We sought comment on this
    recommendation in the *CMAS NPRM*.[^246] Several commenters support
    the 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 . . ."[^247] Motorola supports this view and
    notes that inclusion of additional information and characters beyond
    90 characters will strain the network, causing few people to receive
    the alert.[^248] AAPC states that the 90 character limit strikes an
    appropriate balance between complexity and a reasonably constructed
    CMAS.[^249] Other commenters raised concerns that a 90 character
    limit would not provide sufficient information to subscribers about
    emergencies. For example, CellCast states in their comments that 90
    characters alone is insufficient to convey a complete alert to
    mobile devices.[^250] Furthermore, one commenter stated that the
    "character count recommendations are reasonable for display of
    'basic' warnings but CMSAAC recommendations should accommodate
    supplemental and verbose message formats."[^251]

83. We conclude that, at this initial stage, adoption of a 90 character
    limit serves the public interest. We agree with commenters such as
    MetroPCS that a 90 character limit will allow all systems to
    transmit the message with minimal change, and that 90 characters is
    an effective limit to allow the message to be delivered and actually
    be read.[^252] As the CMSAAC concluded and the Wireless
    Rehabilitation Engineering Research Center (WRERC) notes, the 90
    character text limit of any CMAS alert is reasonable because the
    CMAS alert is intended to get the attention of a person. The person
    can then seek out other media for confirmation of the alert and more
    information.[^253]

84. The CMSAAC also recommended that where the alert coming into the
    Alert Gateway contains a link to an Internet web site (or URL) as a
    resource element, the Alert Gateway would retrieve any file
    specified by the URL and deliver that file to the CMS Provider
    Gateway. This is a different issue from the URL in free text issue
    discussed above, because it implicates the manner in which the alert
    is sent to the CMS Provider Gateway, as opposed to the actual
    content of the alert itself. We agree with the CMSAAC that CMS
    provider networks do not have the resources to process alerts with
    internet links. Further, URLs may link the CMS Provider Gateway to
    untrusted Internet sites that could fall outside the security
    requirements that the electing CMS providers have indicated are an
    essential element of the CMAS. Accordingly, in the CMS provider
    profile, no alerts with internal URLs may be accepted.[^254] Rather,
    related files or other resource elements must be provided separately
    by the Alert Gateway to the CMS Provider Gateway.

85. We also adopt the CMSAAC observation that the CMAS profiles will not
    be able to accommodate real-time content, including a Presidential
    alert, even in text format. We believe that the CMSAAC has given
    sufficient indication of the limits of current CMS provider
    architecture to support this conclusion. Currently, the only
    real-time alert that could potentially be provided to the CMAS is
    the Presidential alert (Emergency Alert Notification or EAN). In the
    event that such a significant event were to occur, all broadcast
    media would be carrying the message, and as the Wireless RERC
    recommends, instructing the public to tune to their local radio and
    television station and other mass media is the best option for
    obtaining additional emergency information.[^255]

86. The text profiles we adopt today are reflected in table below:

Text Profile

  --------------------------------------------------------------------------------------------
  **Service Profile:                                                 
  Text_Universal_Service_Profile**                                   
  ---------------------------------- ------------------------------- -------------------------
  **Attribute Name**                 **Attribute Definition**        **Note**

  Purpose                            Common denominator for text     
                                     messages                        

  Maximum Payload Size               120 bytes                       Size is estimated

  Maximum Displayable Message Size   90 characters for an English    Languages other than
                                     language CMA encoded with 7-bit English, or coding other
                                     encoding                        then 7-bit coding, will
                                                                     result in a change to the
                                                                     maximum number of
                                                                     characters supported

  Data Coding Scheme                 UTF-8 as defined in IETF        The text provided over
                                     RFC-3629                        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.
  --------------------------------------------------------------------------------------------

## Security for CMAS Alerts 

87. The CMSAAC recommended a specific Alert Aggregator and Alert Gateway
    Trust Model to assure the security, authentication and authorization
    of alerts from the Alert initiator to the CMS Provider Gateway. The
    CMSAAC also recommended security requirements for communications
    across the "C" interface between the Alert Gateway and CMS Provider
    Gateways and within each CMS 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.[^256]

88. We find that an IP-based communications across the "C" interface
    serves the public interest because it would enhance the security of
    the CMAS. Accordingly, we adopt the CMSAAC's recommendation. We
    disagree with Purple Tree Technologies' concerns that the protocols
    put forth are insufficient to provide the security required, and
    that a higher layer security protocol is necessary over the "C"
    interface between the Alert and CMS Provider Gateways.[^257] Rather,
    we agree with Verizon Wireless, which in its Reply Comments rejects
    such a need.[^258] As Verizon Wireless correctly points out, under
    the CMAS Reference Architecture, which we have adopted in this
    Order, the need for higher layer security protocols exists only as
    an element of the "Trust Model," which addresses the linkage between
    the Alert Gateway and alert initiators.[^259] By the time the Alert
    Gateway hands off a particular alert to the CMS Provider Gateway,
    any necessary authentication and authorization has been completed,
    thus obviating the need for a higher level security layer over the
    "C" interface.

89. The CMSAAC recommended that the security at Reference Points D and E
    be based upon CMS provider policies and upon the capabilities of the
    CMS provider selected delivery technologies. No commenter opposes
    this recommendation, and we believe that the recommendation is
    consistent with the technologically neutral policy of this order and
    is consistent with section 602(a) of the WARN Act which requires
    that we adopt technical requirements necessary to facilitate
    emergency alert capabilities of CMS providers. Accordingly, we adopt
    this recommendation of the CMSAAC.

## CMAS Reliability and Performance

90. The CMSAAC made general recommendations concerning CMAS system
    performance requirements. Most requirements are prospective
    observations and recommendations. Major ones include:

-   [Alert Gateway capacity.]{.underline} 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.]{.underline} 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.]{.underline} 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.

91. In order to assure the reliability and performance of this new
    system, the CMSAAC recommended procedures for logging CMAS alerts at
    the Alert Gateway and for testing the system at the Alert Gateway
    and on an end-to-end basis. Because this presumes the existence of
    an entity acting in the role of Alert Aggregator/Gateway, we cannot
    adopt rules in this area at this time.[^260]

## Timeline for Implementation of Technical Requirements, Standards and Protocols.

92. In its recommendations, the CMSAAC proposed a specific timeline for
    the implementation of the CMAS. According to the CMSAAC, it would
    take a minimum of 24 months from the date by which CMS providers
    must elect to participate in the CMAS under section 602(b)(2)(A) of
    the WARN Act) to deploy the CMAS.[^261] The CMSAAC proposed
    deployment timeline was based upon the assumptions that (1) the
    CMSAAC recommendations contained within this document are accepted
    without any major technical changes and (2) the government
    documentation and deliverables are available at the milestone dates
    indicated on the timeline. In this regard, the CMSAAC also assumed
    that the requirements, development, and deployments of the Alert
    Gateway and Alert Aggregator would align with the CMS provider
    developments to allow for testing during the development process and
    prior to CMAS deployments. The CMSAAC recommended timeline assumed
    that Federal Government interface specifications would be available
    in January, 2008, 10 months before CMAS development and testing was
    to begin.

93. At the outset we note that the majority of commenters that addressed
    the issue supported the CMSAAC's proposed deployment timeline.[^262]
    Further, in its comments, FEMA asked the Commission not to adopt an
    effective date for these rules until all legal issues regarding the
    Federal 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.[^263]

94. Issues related to the CMSAAC proposed timeline fall under the
    election provisions of section 602(b) of the WARN Act, and so are
    not strictly within the purview of this initial technical order that
    complies with section 602(a). However, we agree with the CMSAAC that
    the Alert Aggregator and Alert Gateway must be in place in order for
    CMS providers to complete development of the CMAS and to begin
    receiving and transmitting emergency alerts.

95. Accordingly, CMS providers must comply with the technical rules we
    adopt today no later than 10 months from the date of announcement of
    an entity to provide the Alert Aggregator and Alert Gateway
    functions.[^264] This time period is consistent with the 10 months
    the CMSAAC proposed timeline indicates would elapse between the
    availability of the Aggregator/Gateway interface design
    specification and the beginning of CMAS development and testing. We
    believe that this will give the government and industry stakeholders
    sufficient time to the federal government\'s role. It will also give
    electing CMS providers adequate time to come into compliance with
    the rules adopted herein.[^265]

# Procedural Matters

## Final Regulatory Flexibility Act Analysis

96. As required by section 603 of the Regulatory Flexibility Act (RFA),
    5 U.S.C. § 604, the Commission has prepared a Final Regulatory
    Flexibility Analysis of the possible impact of the rule changes
    contained in this Report and Order on small entities. The Final
    Regulatory Flexibility Act analysis is set forth in Appendix B,
    *infra*. The Commission's Consumer & Government Affairs Bureau,
    Reference Information Center, will send a copy of this Report and
    Order, including the Final Regulatory Flexibility Act Analysis, to
    the Chief Counsel for Advocacy of the Small Business Administration.

## Final Paperwork Reduction Act of 1995 Analysis

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

## Congressional Review Act Analysis

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

## Alternative Formats

99. Alternative formats (computer diskette, large print, audio cassette,
    and Braille) are available to persons with disabilities by sending
    an e-mail to <FCC504@fcc.gov> or calling the Consumer and
    Governmental Affairs Bureau at (202) 418-0530, TTY (202) 418-0432.

# Ordering ClauseS

100. IT IS ORDERED, that pursuant to sections 1, 4(i) and (o), 201,
     303(r), 403, and 706 of the Communications Act of 1934, as amended,
     47 U.S.C. §§ 151, 154(i) and (o), 201, 303(r), 403, and 606, as
     well as by sections 602(a),(b),(c), (f), 603, 604 and 606 of the
     WARN Act, this Report and Order IS hereby ADOPTED. The rules
     adopted in this Report and Order shall become effective 30 days
     after publication in the Federal Register except that the new
     information collection requirements contained in these rules will
     not become effective prior to OMB approval.[^266]

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

     FEDERAL COMMUNICATIONS COMMISSION

Marlene H. Dortch

Secretary

**APPENDIX A**

**List of Commenters**

**Comments in PS Docket No. 07-287**

**[Commenters]{.underline}** **[Abbreviation]{.underline}**

3G Americas 3G Americas

Acision B.V. and One2Many B.V. Acision

Alliance for Telecommunications Industry Solutions ATIS

Alltel Communications, LLC Alltel

American Association of Paging Carriers AAPC

America\'s Emergency Network AEN

Association of Public Television Stations APTS

AT&T Inc. AT&T

Audemat-Aztec Inc. Audemat-Aztec

California Public Utilities Commission CAPUC

CellCast Technologies, LLC CellCast

Cellular Emergency Alert Service Association -- US Chapter CEASA-US

CTIA -- The Wireless Association CTIA

DataFM, Inc. DataFM

Digital Alert Systems, LLC DAS

Ericsson Inc. Ericsson

Florida Association of Broadcasters FAB

Global Security Systems, LLC Global

Interstate Wireless Inc. Interstate Wireless

Jacob Westfall Westfall

Kendall Post Post

Max Mayfield Mayfield

MetroPCS Communications, Inc. MetroPCS

Mississippi Association of Broadcasters Mississippi Broadcasters

Mississippi Emergency Management Agency MS-EMA

Mississippi Office of Homeland Security MS-OHS

Motorola, Inc. Motorola

National Association of Broadcasters NAB

National Emergency Numbering Association NENA

Nokia Inc. and Nokia Siemens Networks US LLC Nokia

Pontotoc County Emergency Management Agency Pontotoc EMA

Purple Tree Technologies PTT

Rehabilitation Engineering Research Center

> for Wireless Technologies Wireless RERC

Rural Cellular Association RCA

Sheriff, Jefferson Davis Parish, Louisiana Sheriff

SouthernLINC Wireless SouthernLINC

Sprint Nextel Corporation Sprint Nextel

SquareLoop, Inc. SquareLoop

Telecommunications Industry Association TIA

T-Mobile USA, Inc. T-Mobile

Verizon Wireless Verizon

**[Reply Commenters]{.underline}** **[Abbreviation]{.underline}**

Airadigm Communications - Einstein Wireless Airadigm

Alltel Communications, LLC Alltel

American Association of Paging Carriers AAPC

Association of Public Television Stations APTS

AT&T Inc. AT&T

CellCast Technologies, LLC CellCast

CTIA -- The Wireless Association CTIA

Cox Radio, Inc. Cox

DataFM, Inc. DataFM

FEMA, Director, Office of Nat'l Security Coordination FEMA

Global Security Systems, LLC Global

Interstate Wireless Inc. Interstate Wireless

King County, Washington King County

Motorola, Inc. Motorola

National Telecommunications Cooperative Association NTCA

NTI Group, Inc. NTI

OnStar Corporation OnStar

Rural Cellular Association RCA

SquareLoop, Inc. SquareLoop

T-Mobile USA, Inc. T-Mobile

Verizon Wireless Verizon

**[Ex Parte Commenters]{.underline}** **[Abbreviation]{.underline}**

American Association of Paging Carriers AAPC

AT&T Inc. AT&T

CTIA -- The Wireless Association CTIA

DataFM, Inc. DataFM

Global Security Systems, LLC Global

National Telecommunications Cooperative Association NTCA

OnStar Corporation OnStar

Rural Cellular Association RCA

**APPENDIX B**

**Final Regulatory Flexibility Analysis**

1.  As required by the Regulatory Flexibility Act of 1980, as amended
    (RFA),[^267] 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).[^268] In
    addition, the *CMAS NPRM* and IRFA were published in the Federal
    Register.[^269]

## Need for, and Objectives of, the Order

102. 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."[^270] Although the
     *CMAS NPRM* solicited comment on issues related to section 602(b)
     (CMS provider election to the CMAS) or 602(c) (Public Television
     Station equipment requirements), this CMAS First Report and Order
     only addresses issues raised by section 602(a) of the WARN
     Act.[^271] 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.

103. This CMAS First Report and Order adopts rules necessary to enable
     CMS alerting capability for CMS providers who elect to transmit
     emergency alerts to their subscribers. The Order adopts
     technologically neutral rules governing the CMS provider-related
     functions and responsibilities with respect to the CMAS.
     Specifically, the rules address the CMS providers' functions within
     the CMAS, including CMS provider-controlled elements within the
     CMAS architecture, emergency alert formatting, classes and
     elements, geographic targeting (geo-targeting) and accessibility
     for people with disabilities and the elderly.

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

104. 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.[^272]
     Although Interstate Wireless did not comment specifically on the
     IRFA, it did state that the cost of building and maintaining a CMS
     Provider Gateway would be more than it and other similarly situated
     Small Business CMS providers could afford and still be able to
     provide the alert service to the public without cost. Accordingly,
     Interstate Wireless requested that the Federal Government either
     provide the proper software and reception equipment for the CMS
     Provider Gateways, or provide grants to the Small Business CMS
     providers to purchase, install, and maintain the equipment
     themselves. In paragraph 19, note 58 of the CMAS First Report and
     Order the Commission notes that questions of funding are not
     addressed by section 602(a) of the WARN Act and are this outside of
     the scope of this order.[^273]

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

105. 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.[^274] The RFA generally
     defines the term "small entity" as having the same meaning as the
     terms "small business," "small organization," and "small
     governmental jurisdiction."[^275] In addition, the term "small
     business" has the same meaning as the term "small business concern"
     under the Small Business Act.[^276] 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).[^277]

106. [Wireless Telecommunications Carriers (except
     Satellite).]{.underline} Since 2007, the SBA has recognized
     wireless firms within this new, broad, economic census
     category.[^278] 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."[^279] Under the present and prior categories,
     the SBA has deemed a wireless business to be small if it has 1,500
     or fewer employees. Because Census Bureau data are not yet
     available for the new category, we will estimate small business
     prevalence using the prior categories and associated data. For the
     first category of Paging, data for 2002 show that there were 807
     firms that operated for the entire year.[^280] Of this total, 804
     firms had employment of 999 or fewer employees, and three firms had
     employment of 1,000 employees or more.[^281] 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.[^282] Of this total, 1,378 firms had employment of 999
     or fewer employees, and 19 firms had employment of 1,000 employees
     or more.[^283] Thus, using the prior categories and the available
     data, we estimate that the majority of wireless firms can be
     considered small.

107. [Cellular Service]{.underline}*.* As noted, the SBA has developed a
     small business size standard for small businesses in the category
     "Wireless Telecommunications Carriers (except satellite)."[^284]
     Under that SBA category, a business is small if it has 1,500 or
     fewer employees.[^285] Since 2007, the SBA has recognized wireless
     firms within this new, broad, economic census category.[^286] 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."[^287] Accordingly, the pertinent data for this
     category is contained within the prior [Wireless Telecommunications
     Carriers (except Satellite]{.underline}) category.

108. [Auctions.]{.underline} Initially, we note that, as a general
     matter, the number of winning bidders that qualify as small
     businesses at the close of an auction does not necessarily
     represent the number of small businesses currently in service.
     Also, the Commission does not generally track subsequent business
     size unless, in the context of assignments or transfers, unjust
     enrichment issues are implicated.

109. *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.[^288] 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.[^289] These small business size standards, in the
     context of broadband PCS auctions, have been approved by the
     SBA.[^290] 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.[^291] On March 23, 1999, the
     Commission reauctioned 155 C, D, E, and F Block licenses; there
     were 113 small business winning bidders.[^292] On January 26, 2001,
     the Commission completed the auction of 422 C and F PCS licenses in
     Auction 35.[^293] 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.

110. *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.[^294] Through these auctions, the Commission awarded a total
     of forty-one licenses, 11 of which were obtained by four small
     businesses.[^295] 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*.[^296] 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.[^297] 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.[^298] The SBA has approved these small business size
     standards.[^299] A third auction commenced on October 3, 2001 and
     closed on October 16, 2001. Here, five bidders won 317 (MTA and
     nationwide) licenses.[^300] Three of these claimed status as a
     small or very small entity and won 311 licenses.

111. [Wireless Communications Services]{.underline}*.* 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.[^301] The SBA has approved these definitions.[^302] 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.

112. [700 MHz Guard Bands Licenses.]{.underline} 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.[^303] A small business in this service is
     an entity that, together with its affiliates and controlling
     principals, has average gross revenues not exceeding \$40 million
     for the preceding three years.[^304] 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.[^305] SBA
     approval of these definitions is not required.[^306] 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.[^307] 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.[^308] 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).[^309] 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.[^310] Accordingly, at this time there are 54
     licenses in the 700 MHz Guard Bands.

113. [700 MHz Band Commercial Licenses.]{.underline} 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.[^311] 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.[^312] The SBA has approved these small size
     standards.[^313]

114. 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.[^314] 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.[^315] 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.[^316]

115. 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."

116. [Advanced Wireless Services.]{.underline} 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.[^317] 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.[^318] 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.

117. [Common Carrier Paging]{.underline}*.* 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).\"[^319] 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.[^320] 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."[^321] Under the
     present and prior categories, the SBA has deemed a wireless
     business to be small if it has 1,500 or fewer employees. Because
     Census Bureau data are not yet available for the new category, we
     will estimate small business prevalence using the prior categories
     and associated data. For the first category of Paging, data for
     2002 show that there were 807 firms that operated for the entire
     year.[^322] Of this total, 804 firms had employment of 999 or fewer
     employees, and three firms had employment of 1,000 employees or
     more.[^323] 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.[^324] Of this total, 1,378 firms
     had employment of 999 or fewer employees, and 19 firms had
     employment of 1,000 employees or more.[^325] Thus, using the prior
     categories and the available data, we estimate that the majority of
     wireless firms can be considered small. Thus, under this category,
     the majority of firms can be considered small.

118. In the Paging *Third Report and Order*, we developed a small
     business size standard for "small businesses" and "very small
     businesses" for purposes of determining their eligibility for
     special provisions such as bidding credits and installment
     payments.[^326] 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.[^327] The SBA has approved these small business size
     standards.[^328] An auction of Metropolitan Economic Area licenses
     commenced on February 24, 2000, and closed on March 2, 2000.[^329]
     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.[^330] Of those, we estimate that
     360 are small, under the SBA-approved small business size
     standard.[^331]

119. [Wireless Communications Service]{.underline}. 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.[^332] 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.[^333] 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.

120. [Wireless Communications Equipment Manufacturers]{.underline}.
     While these entities are merely indirectly affected by our action,
     we are describing them to achieve a fuller record. The Census
     Bureau defines this category as follows: "This industry comprises
     establishments primarily engaged in manufacturing radio and
     television broadcast and wireless communications equipment.
     Examples of products made by these establishments are: transmitting
     and receiving antennas, cable television equipment, GPS equipment,
     pagers, cellular phones, mobile communications equipment, and radio
     and television studio and broadcasting equipment." The SBA has
     developed a small business size standard for Radio and Television
     Broadcasting and Wireless Communications Equipment Manufacturing,
     which is: all such firms having 750 or fewer employees.[^334]
     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.[^335]

121. [Radio and Television Broadcasting and Wireless Communications
     Equipment Manufacturing]{.underline}*.* 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."[^336] 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.[^337] According to Census
     Bureau data for 2002, there were a total of 1,041 establishments in
     this category that operated for the entire year.[^338] Of this
     total, 1,010 had employment of under 500, and an additional 13 had
     employment of 500 to 999.[^339] Thus, under this size standard, the
     majority of firms can be considered small.

122. [Software Publishers]{.underline}. While these entities are merely
     indirectly affected by our action, we are describing them to
     achieve a fuller record. These companies may design, develop or
     publish software and may provide other support services to software
     purchasers, such as providing documentation or assisting in
     installation. The companies may also design software to meet the
     needs of specific users. The SBA has developed a small business
     size standard of \$23 million or less in average annual receipts
     for the category of Software Publishers. For Software Publishers,
     Census Bureau data for 2002 indicate that there were 6,155 firms in
     the category that operated for the entire year. Of these, 7,633 had
     annual receipts of under \$10 million, and an additional 403 firms
     had receipts of between \$10 million and \$24, 999,999. For
     providers of Custom Computer Programming Services, the Census
     Bureau data indicate that there were 32,269 firms that operated for
     the entire year. Of these, 31,416 had annual receipts of under \$10
     million, and an additional 565 firms had receipts of between \$10
     million and \$24,999,999. Consequently, we estimate that the
     majority of the firms in this category are small entities that may
     be affected by our action.

123. [NCE and Public Broadcast Stations]{.underline}. 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."[^340] 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.[^341]
     According to Commission staff review of the BIA Publications, Inc.,
     Master Access Television Analyzer Database as of May 16, 2003,
     about 814 of the 1,220 commercial television stations in the United
     States had revenues of \$12 (twelve) million or less. We note,
     however, that in assessing whether a business concern qualifies as
     small under the above definition, business (control)
     affiliations[^342] must be included. Our estimate, therefore,
     likely overstates the number of small entities that might be
     affected by our action, because the revenue figure on which it is
     based does not include or aggregate revenues from affiliated
     companies.

124. In addition, an element of the definition of "small business" is
     that the entity not be dominant in its field of operation. We are
     unable at this time to define or quantify the criteria that would
     establish whether a specific television station is dominant in its
     field of operation. Accordingly, the estimate of small businesses
     to which rules may apply do not exclude any television station from
     the definition of a small business on this basis and are therefore
     over-inclusive to that extent. Also as noted, an additional element
     of the definition of "small business" is that the entity must be
     independently owned and operated. We note that it is difficult at
     times to assess these criteria in the context of media entities and
     our estimates of small businesses to which they apply may be
     over-inclusive to this extent. There are also 2,117 low power
     television stations (LPTV).[^343] Given the nature of this service,
     we will presume that all LPTV licensees qualify as small entities
     under the above SBA small business size standard.

125. The Commission has, under SBA regulations, estimated the number of
     licensed NCE television stations to be 380.[^344] We note, however,
     that, in assessing whether a business concern qualifies as small
     under the above definition, business (control) affiliations[^345]
     must be included. Our estimate, therefore, likely overstates the
     number of small entities that might be affected by our action,
     because the revenue figure on which it is based does not include or
     aggregate revenues from affiliated companies. The Commission does
     not compile and otherwise does not have access to information on
     the revenue of NCE stations that would permit it to determine how
     many such stations would qualify as small entities.

```{=html}
<!-- -->
```
A.  **Description of Projected Reporting, Recordkeeping, and Other
    Compliance Requirements**

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

```{=html}
<!-- -->
```
B.  **Steps Taken to Minimize the Significant Economic Impact on Small
    Entities, and Significant Alternatives Considered**

```{=html}
<!-- -->
```
127. 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."[^346]

128. As noted in paragraph 2 above, this CMAS First Report and Order
     deals only with the WARN Act section 602(a) requirement that the
     Commission adopt technical standards, protocols, procedures, and
     other technical requirements based on the recommendations of the
     Commercial Mobile Service Alert Advisory Committee. The entities
     affected by this order were largely the members of the CMSAAC. In
     its formation of the CMSAAC, the Commission made sure to include
     representatives of small businesses among the advisory committee
     members. Also, as we indicate by our treatment of the comments of
     Interstate Wireless in paragraph 15 above, the technical
     requirements, standards and protocols on which the Commission
     sought comment already contain concerns raised by small
     businesses.[^347] The WARN ACT NPRM also sought comment on a number
     of alternatives to the recommendations of the CMSAAC, such as the
     Digital EAS[^348] and FM sub-carrier based alerts.[^349] In its
     consideration of these and other alternatives the CMSAAC
     recommendations, the Commission has attempted to impose minimal
     regulation on small entities to the extent consistent with our goal
     of advancing our public safety mission by adopting technical
     requirements, standards and protocols for a CMAS that CMS providers
     would elect to provide alerts and warnings to their customers. The
     affected CMS providers have overwhelmingly expressed their
     willingness to cooperate in the formation of the CMAS, and we
     anticipate that the standards, protocols and requirement that we
     adopt in this order will encourage CMS providers to work with other
     industry and government entities to complete and participate in the
     CMAS.

```{=html}
<!-- -->
```
C.  **Federal Rules that May Duplicate, Overlap, or Conflict with the
    Proposed Rules**

```{=html}
<!-- -->
```
129. None.

**APPENDIX C**

**Final Rules**

**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**

Sec.

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**

Sec.

10.400 Classification.

10.410 Prioritization.

10.420 Message Elements.

10.430 Character Limit.

10.440 Embedded Reference Prohibition.

10.450 Geographic Targeting.

10.460 Retransmission Frequency (reserved).

10.470 Roaming.

**Subpart E---Equipment Requirements**

Sec.

10.500 General Requirements.

10.510 Call Preemption Prohibition.

10.520 Common Audio Attention Signal.

10.530 Common Vibration Cadence.

10.540 Attestation Requirement. (reserved).

**Subpart A---General Information**

**§ 10.1 Basis.**

The rules in this part are issued pursuant to the authority contained in
the Warning, Alert, and Response Network Act, Title VI of the Security
and Accountability for Every Port Act of 2006, Pub. L. 109-347, Titles I
through III of the Communications Act of 1934, as amended, and Executive
Order 13407 of June 26, 2006, Public Alert and Warning System, 71
Federal Register 36975 (2006).

**§ 10.2 Purpose.**

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

**§ 10.10 Definitions.**

\(a\) *Alert Message.* An Alert Message is a message that is intended to
provide the recipient information regarding an emergency, and that meets
the requirements for transmission by a Participating Commercial Mobile
Service Provider under this part.

\(b\) *Common Alerting Protocol*. The Common Alerting Protocol (CAP)
refers to Organization for the Advancement of Structured Information
Standards (OASIS) Standard CAP-V1.1, October 2005 (available at
<http://www.oasis-open.org/specs/index.php#capv1.1>), or any subsequent
version of CAP adopted by OASIS and implemented by the CMAS.

\(c\) *Commercial Mobile Alert System*. The Commercial Mobile Alert
System (CMAS) refers to the voluntary emergency alerting system
established by this part, whereby Commercial Mobile Service Providers
may elect to transmit Alert Messages to the public.

\(d\) *Commercial Mobile Service Provider*. A Commercial Mobile Service
Provider (or CMS Provider) is an FCC licensee providing commercial
mobile service as defined in section 332 (d)(1) of the Communications
Act of 1934 (47 U.S.C. 332(d)(1)). Section 332(d)(1) defines the term
commercial mobile service as any mobile service (as defined in 47 U.S.C.
153) that is provided for profit and makes interconnected service
available (a) to the public or (b) to such classes of eligible users as
to be effectively available to a substantial portion of the public, as
specified by regulation by the Commission.

\(g\) *County and County Equivalent*. The terms County and County
Equivalent as used in this part are defined by Federal Information
Processing Standards (FIPS) 6-4, which provides the names and codes that
represent the counties and other entities treated as equivalent legal
and/or statistical subdivisions of the 50 States, the District of
Columbia, and the possessions and freely associated areas of the United
States. Counties are considered to be the "first-order subdivisions" of
each State and statistically equivalent entity, regardless of their
local designations (county, parish, borough, *etc*.). Thus, the
following entities are considered to be equivalent to counties for legal
and/or statistical purposes: The parishes of Louisiana; the boroughs and
census areas of Alaska; the District of Columbia; the independent cities
of Maryland, Missouri, Nevada, and Virginia; that part of Yellowstone
National Park in Montana; and various entities in the possessions and
associated areas. The FIPS codes and FIPS code documentation are
available online at <http://www.itl.nist.gov/fipspubs/index.htm>.

\(f\) *Participating Commercial Mobile Service Provider.* A
Participating Commercial Mobile Service Provider (or a Participating CMS
Provider) is a Commercial Mobile Service Provider that has voluntarily
elected to transmit Alert Messages under subpart B of this part.

**§ 10.11 CMAS Implementation Timeline.**

Notwithstanding anything in this part to the contrary, a Participating
CMS provider shall comply with the rules in this part no later than 10
months from the date of announcement by the FCC of an entity or entities
to provide the Alert Aggregator and Federal alert gateway functions.

**Subpart B---Election to Participate in Commercial Mobile Alert
System**

Reserved.

**Subpart C---System Architecture**

**§ 10.300 Alert Aggregator.**

Reserved.

**§ 10.310 Federal Alert Gateway.**

Reserved.

**§ 10.320 Provider Alert Gateway Requirements.**

This section specifies the functions that each Participating Commercial
Mobile Service provider is required to support and perform at its CMS
provider gateways.

\(a\) *General*. The CMS provider gateway must provide secure,
redundant, and reliable connections to receive Alert Messages from the
Federal alert gateway. Each CMS provider gateway must be identified by a
unique IP address or domain name.

\(b\) *Authentication and Validation*. The CMS provider gateway must
authenticate interactions with the Federal alert gateway, and validate
Alert Message integrity and parameters. The CMS provider gateway must
provide an error message immediately to the Federal alert gateway if a
validation fails.

\(c\) *Security*. The CMS provider gateway must support standardized
IP-based security mechanisms such as a firewall, and support the defined
CMAS "C" interface and associated protocols between the Federal alert
gateway and the CMS provider gateway.

\(d\) *Geographic Targeting*. The CMS provider gateway must determine
whether the provider has elected to transmit an Alert Message within a
specified alert area and, if so, map the Alert Message to an associated
set of transmission sites.

\(e\) *Message Management*.

\(1\) Formatting. The CMS provider gateway is not required to perform
any formatting, reformatting, or translation of an Alert Message, except
for transcoding a text, audio, video, or multimedia file into the format
supported by mobile devices.

\(2\) Reception. The CMS provider gateway must support a mechanism to
stop and start Alert Message deliveries from the Federal alert gateway
to the CMS provider gateway.

\(3\) Prioritization. The CMS provider gateway must process an Alert
Message on a first in--first out basis except for Presidential Alerts,
which must be processed before all non-Presidential alerts.

\(4\) Distribution. A Participating CMS provider must deploy one or more
CMS provider gateways to support distribution of Alert Messages and to
manage Alert Message traffic.

\(5\) Retransmission. The CMS provider gateway must manage and execute
Alert Message retransmission, and support a mechanism to manage
congestion within the CMS provider's infrastructure.

\(f\) *CMS Provider Profile*. The CMS provider gateway will provide
profile information on the CMS provider for the Federal alert gateway to
maintain at the Federal alert gateway. This profile information must be
provided by an authorized CMS provider representative to the Federal
alert gateway administrator. The profile information must include the
data listed in Table 10.320(f) and must comply with the following
procedures:

\(1\) The information must be provided 30 days in advance of the date
when the CMS provider begins to transmit CMAS alerts.

\(2\) Updates of any CMS provider profiles must be provided in writing
at least 30 days in advance of the effective change date.  

> Table 10.320(f) CMSP Profile on Federal Alert Gateway

+--------------------+--------------------+----------------------------+
| **Profile          | **Parameter        | **Description**            |
| Parameter**        | Election**         |                            |
+====================+====================+============================+
| CMSP Name          |                    | Unique identification of   |
|                    |                    | CMSP                       |
+--------------------+--------------------+----------------------------+
| CMSP gateway       | IP address or      |                            |
| Address            | Domain Name        |                            |
+--------------------+--------------------+----------------------------+
|                    | Alternate IP       | Optional and subject to    |
|                    | address            | implementation             |
+--------------------+--------------------+----------------------------+
| Geo-Location       | \<yes / no\>       | If "yes" the only CMAM     |
| Filtering          |                    | 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  | CMAC Geocode for   | List can be state name or  |
| > states           | state              | abbreviated state name.    |
+--------------------+--------------------+----------------------------+

**§ 10.330 Provider Infrastructure Requirements.**

This section specifies the general functions that a Participating CMS
Provider is required to perform within their infrastructure.
Infrastructure functions are dependent upon the capabilities of the
delivery technologies implemented by a Participating CMS Provider.

\(a\) Distribution of Alert Messages to mobile devices.

\(b\) Authentication of interactions with mobile devices.

\(c\) Reference Points D & E. Reference Point D is the interface between
a CMS Provider gateway and its infrastructure. Reference Point E is the
interface between a provider's infrastructure and mobile devices
including air interfaces. Reference Points D and E protocols are defined
and controlled by each Participating CMS Provider.

**Subpart D---Alert Message Requirements**

**§ 10.400 Classification.**

A Participating CMS Provider is required to receive and transmit three
classes of Alert Messages: Presidential Alert; Imminent Threat Alert;
and Child Abduction Emergency/AMBER Alert.

\(a\) *Presidential Alert*. A Presidential Alert is an alert issued by
the President of the United States or the President's authorized
designee.

\(b\) *Imminent Threat Alert*. An Imminent Threat Alert is an alert that
meets a minimum value for each of three CAP elements: Urgency, Severity,
and Certainty.

\(1\) Urgency. The CAP Urgency element must be either Immediate (*i.e.*,
responsive action should be taken immediately) or Expected (*i.e.*,
responsive action should be taken soon, within the next hour).

\(2\) Severity. The CAP Severity element must be either Extreme (*i.e.*,
an extraordinary threat to life or property) or Severe (*i.e.*, a
significant threat to life or property).

\(3\) Certainty. The CAP Certainty element must be either Observed
(*i.e.*, determined to have occurred or to be ongoing) or Likely
(*i.e.*, has a probability of greater than 50 percent).

\(c\) *Child Abduction Emergency/AMBER Alert*. 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: (1) law enforcement confirms a child has been abducted;
(2) the child is 17 years or younger; (3) law enforcement believes the
child is in imminent danger of serious bodily harm or death; (4) there
is enough descriptive information about the victim and the abduction to
believe an immediate broadcast alert will help; and (5) the child's name
and other data have been entered into the National Crime Information
Center. There are four types of AMBER Alerts: Family Abduction;
Non-family Abduction; Lost, Injured or Otherwise Missing; and Endangered
Runaway.

\(1\) Family Abduction. A Family Abduction (FA) alert involves an
abductor who is a family member of the abducted child such as a parent,
aunt, grandfather, or stepfather.

\(2\) Nonfamily Abduction. A Nonfamily Abduction (NFA) alert involves an
abductor unrelated to the abducted child, either someone unknown to the
child and/or the child's family or an acquaintance/friend of the child
and/or the child's family.

\(3\) 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.

\(4\) Endangered Runaway. An Endangered Runaway (ERU) alert involves a
missing child who is believed to have run away and in imminent danger.

**§ 10.410 Prioritization.**

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

**§ 10.420 Message Elements.**

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

**§ 10.430 Character Limit.**

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

**§ 10.440 Embedded Reference Prohibition.**

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

**§ 10.450 Geographic Targeting.**

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

**§ 10.460 Retransmission Frequency.**

Reserved.

**§ 10.470 Roaming.**

[]{.mark}

When, pursuant to a roaming agreement (*see* § 20.12 of the
Commission\'s rules), a subscriber receives services from a roamed-upon
network of a Participating CMS Provider, the Participating CMS Provider
must support CMAS alerts to the roaming subscriber to the extent the
subscriber's mobile device is configured for and technically capable of
receiving CMAS alerts..

**Subpart E---Equipment Requirements**

**§ 10.500 General Requirements**.

CMAS mobile device functionality is dependent on the capabilities of a
Participating CMS Provider's delivery technologies. Mobile devices are
required to perform the following functions:

\(a\) Authentication of interactions with CMS Provider infrastructure.

\(b\) Monitoring for Alert Messages.

\(c\) Maintaining subscriber alert opt-out selections, if any.

\(d\) Maintaining subscriber alert language preferences, if any.

\(e\) Extraction of alert content in English or the subscriber's
preferred language, if applicable.

\(f\) Presentation of alert content to the device, consistent with
subscriber opt-out selections. Presidential Alerts must always be
presented.

\(g\) Detection and suppression of presentation of duplicate alerts.

**§ 10.510 Call Preemption Prohibition.**

Devices marketed for public use under Part 10 must not enable an Alert
Message to preempt an active voice or data session.

**§ 10.520 Common Audio Attention Signal.**

A Participating CMS Provider and equipment manufacturers may only market
devices for public use under Part 10 that include an audio attention
signal that meets the requirements of this section.

\(a\) The audio attention signal must have a temporal pattern of one
long tone of two (2) seconds, followed by two short tones of one (1)
second each, with a half (0.5) second interval between each tone. The
entire sequence must be repeated twice with a half (0.5) second interval
between each repetition.

\(b\) For devices that have polyphonic capabilities, the audio attention
signal must consist of the fundamental frequencies of 853 Hz and 960 Hz
transmitted simultaneously.

\(c\) For devices with only a monophonic capability, the audio attention
signal must be 960 Hz.

\(d\) The audio attention signal must be restricted to use for Alert
Messages under Part 10.

\(e\) A device may include the capability to mute the audio attention
signal.

**§ 10.530 Common Vibration Cadence.**

A Participating CMS Provider and equipment manufacturers may only market
devices for public use under Part 10 that include a vibration cadence
capability that meets the requirements of this section.

\(a\) The vibration cadence must have a temporal pattern of one long
vibration of two (2) seconds, followed by two short vibrations of one
(1) second each, with a half (0.5) second interval between each
vibration. The entire sequence must be repeated twice with a half (0.5)
second interval between each repetition.

\(b\) The vibration cadence must be restricted to use for Alert Messages
under Part 10.

\(c\) A device may include the capability to mute the vibration cadence.

**§ 10.540 Attestation Requirement.**

Reserved.

**STATEMENT OF**

**CHAIRMAN KEVIN J. MARTIN**

*Re:* *The Commercial Mobile Alert System, First Report and Order, PS
Docket No. 07-287*

With the American public increasingly relying on wireless communications
in everyday life, it is essential that we support and advance new ways
to share critical, time-sensitive information with them in times of
crisis. The ability to deliver accurate and timely warnings and alerts
through cell phones and other mobile devices is an important next step
in our efforts to help ensure that the American public has the
information they need to take action to protect themselves and their
families prior to, and during, disasters and other emergencies. The
Commercial Mobile Services Alert Advisory Committee's recommendations
were instrumental in moving this process forward. I commend them for
their efforts

No one questions the value that an effective Commercial Mobile Alert
System will have on the safety and welfare of the American public.
Accordingly, we welcomed the challenge offered to us by the WARN Act as
an opportunity to meet our public safety obligations under the
Communications Act and to achieve one of our top priorities - an
effective alert system for wireless devices.

By adopting technical requirements for the wireless alerting system
today, we are enabling wireless providers that choose to participate in
this system to begin designing their networks to deliver mobile alerts.
It would have been better, of course, if we had a Federal entity in
place now to take on the role of alert aggregator and gateway. We are
hopeful that we have initiated the dialogue that will allow an
appropriate Federal entity to assume that central role in an expeditious
manner.

This system has the potential to significantly impact the way Americans
receive critical warnings on the go, whether they are at home, work, or
vacationing. As we go forward, given the important public safety purpose
that these alerts serve, I encourage wireless providers to participate
fully in this valuable system.

**STATEMENT OF**

**COMMISSIONER MICHAEL J. COPPS**

*Re:* *The Commercial Mobile Alert System, First Report and Order, PS
Docket No. 07-287*

Today's *Order* creates a framework for delivering emergency alerts to
American mobile phones, as required by the Warning Alert Response
Network (WARN) Act. Extending the nation's emergency alert system to
mobile phones is an enormous step forward. Now Americans will be able to
receive warnings about dangerous weather and other imminent threats
(including man-made threats like a terrorist attack) in their immediate
area, even if they are not near a television set or radio and even if
their electrical power is down. This is good news for all of
us---especially in these dangerous times.

I also think it is significant that today's *Order* arises out of
cooperation---through a process established by the WARN Act---among
public safety representatives; government at the state, local and
federal level; federally-recognized Indian tribes; industry; and
national organizations representing those with special needs. For the
most part, the work of the Commercial Mobile Service Alert Advisory
Committee (established by the WARN Act) has been a model of how
difficult and important decisions can be reached, and consensus forged,
even among diverse stakeholders.

The many experts who dedicated their time and energy to this important
effort have made today's decision far more informed, and responsive to
technical realities, than it otherwise would be. I thank them for their
service, and I hope that this spirit of cooperation and shared
dedication to improving public safety can serve as a model for other
public safety issues before the Commission. To be sure, there will be
times when the agency cannot forge consensus and must act based on the
best available evidence before it---because doing so is sometimes
necessary to protect the American public. But the fact remains that the
Commission and industry are both capable of reaching better outcomes
when we work cooperatively, and I hope we can do so more often in the
months and years ahead.

Unfortunately, there is one final issue that remains unresolved by
today's *Order*---an issue that, if left uncorrected, threatens to
vitiate it entirely. So far, no federal agency has stepped up to fulfill
the unified aggregator/gateway role that virtually all stakeholders
agree is necessary for our mobile alert system to work properly. Indeed,
if no agency assumes this role, the rules we enact today will never
become effective and Americans will never receive the protection of
emergency alerts delivered to their mobile phones.

The unwillingness of the Federal Emergency Management Agency (FEMA) to
fulfill this role is especially disheartening because FEMA
representatives were intimately involved in developing the idea of a
unified Federal gateway/aggregator. In fact, not until long after the
die was cast, did FEMA suggest that it would be unable for statutory and
other reasons to perform this key function. Specifically, it was less
than two months ago---***after*** the advisory committee had made its
recommendation and ***after*** FEMA's representative had voted in favor
of the unified Federal gateway/aggregator scheme---before FEMA raised
any objection to assuming this responsibility.

So now we are left without a firm candidate for a position that is
essential to getting this system off the ground. In light of FEMA's
recent and unexpected interpretation of its statutory authority, the
Commission's only remaining option is to work with its fellow agencies
and the Congress to find a federal entity (whether FEMA, another branch
of the Department of Homeland Security, or some other government agency)
that can fulfill this function.

I certainly wish it had not come to this. Indeed, I would not be shy
about suggesting that the FCC take on this function itself---except that
our agency (unlike FEMA, the Department of Justice, and the National
Oceanic and Atmospheric Agency) does not currently have experience with
originating emergency alerts; has not received appropriations for
operating an emergency alert system (as FEMA has); and does not have
statutory authority to borrow money against the DTV Transition Fund to
implement the WARN Act (as the Departments of Homeland Security and
Commerce have).

The time may come when the FCC must consider whether to begin the task
of creating this infrastructure here at our own agency, and I will not
hesitate to head down this road if it looks like the fastest and most
effective way to bring mobile emergency alerts to the American people.
But for now the most fruitful path appears to be working with the
Congress and our fellow federal agencies to see if an institution with
experience originating emergency alerts is willing and able to assume
this role for the CMAS system. I hope---for all of our sakes---that one
will be.

**STATEMENT OF**

**COMMISSIONER JONATHAN S. ADELSTEIN**

*Re:* *The Commercial Mobile Alert System, First Report and Order, PS
Docket No. 07-287*

The prompt and accurate delivery of national, state and local messages
to ensure the safety and security of the American people during natural
or man-made disasters is critical. Today's *Report and Order* marks our
efforts towards ensuring that there are technologically neutral rules in
place to enable commercial mobile service providers to elect to provide
these critical alerts to their customers. With over 250 million
subscribers of wireless services as of the end of this year, the ability
of carriers to transmit emergency alerts to the public via commercial
mobile devices is an urgently needed next step.

One of the central purposes for the very creation of the FCC is to
promote the safety of life and property of all Americans. The Commission
has taken its important role in prescribing these rules very seriously,
so I am pleased to support this decision. This significant step forward
is due, in large part, to the dedication of state and local governments,
industry and other participants that worked collaboratively to provide
us with their recommendations. It is worth remembering that, as an
elective system, it was vital that the rules implementing the Commercial
Mobile Alert System were based upon the coordinated efforts of those
that will implement and utilize this system. Collaboration,
communication and cooperation have been key to this process. The
effectiveness of this emergency alert system rests on the good-faith of
all participating entities and I expect this will go a long way in
ensuring mobile service providers elect to provide these emergency
alerts.

I would like to extend my sincere gratitude to the members of the
Commercial Mobile Service Alert Advisory Committee who worked diligently
through this important process.

**STATEMENT OF**

**COMMISSIONER DEBORAH TAYLOR TATE**

*Re:* *The Commercial Mobile Alert System, First Report and Order, PS
Docket No. 07-287*

With over 255 million Americans subscribing to mobile telephone service,
it is critical to public safety and homeland security that the nation\'s
emergency alert system include wireless alerts. To that end, in 2006
Congress established, via the WARN Act, a process to create a mobile
emergency alert system. Today we take an important step in fulfilling
this goal.

I particularly wish to thank the representatives from industry; public
safety providers; local, state and federal government agencies; and
others who participated in the Commercial Mobile Service Alert Advisory
Committee. The Federal Communications Commission should not - and in
this case, can not - perform its duties without the help of such a broad
coalition, especially the service providers who ultimately must transmit
emergency alerts. I also wish to acknowledge Sen. Jim DeMint for his
leadership in sponsoring the WARN Act and his guidance in its
implementation. Finally, the excellent staff of the Public Safety and
Homeland Security Bureau deserve recognition for their consistent
dedication to this effort.

**STATEMENT OF**

**COMMISSIONER ROBERT M. MCDOWELL**

*Re:* *The Commercial Mobile Alert System, First Report and Order, PS
Docket No. 07-287*

At the outset, I want to acknowledge and thank Lisa Fowlkes, Jean Ann
Collins and all of the team in the Public Safety and Homeland Security
Bureau for their hard work. This project has congressionally-mandated
deadlines, and they have stayed focused on their tasks to produce a
great deal of excellent work in a short period of time.

I also want to thank the folks from private industry and public safety
who are so generously giving of their time and expertise to serve on the
Commercial Mobile Service Alert Advisory Committee and participate in
this important process. This project is an excellent example of the
wonderful benefits that flow from a government-industry collaboration. I
am pleased that the Commission has had a leading role in the meaningful
partnership among the commercial wireless industry, technology providers
and public safety entities.

By harnessing the expertise of all interested stakeholders, we have made
great strides toward the roll-out of an expanded emergency alert system.
We will *all* benefit from the important work this group has undertaken,
and I look forward to continuing to work with all of you as we complete
the next set of benchmarks. At this point, the Commission is already
well poised to "get out of the way" and let the private sector deliver
the new alert system for the benefit of America's wireless consumers.

[^1]: For purposes of section 602 of the Warning, Alert and Response
    Network (WARN) Act, Congress specifically defined "commercial mobile
    service" as that found in section 332(d)(1) of the Communications
    Act of 1934, as amended, 47 U.S.C. § 332(d)(1) (the term "commercial
    mobile service" means any mobile service that is provided for profit
    and makes interconnected service available to the public or to such
    classes of eligible users as to be effectively available to a
    substantial portion of the public, as specified by regulation by the
    Commission). Warning, Alert, and Response Network Act, Title VI of
    the Security and Accountability for Every Port Act of 2006, Pub. L.
    No. 109-347, 120 Stat. 1884, (2006), Titles I through III of the
    Communications Act of 1934, as amended, and Executive Order 13407 of
    June 26, 2006, Public Alert and Warning System, 71 Fed. Reg. 36975
    (June 26, 2006) (WARN Act), § 602(b)(1)(A) (*Executive Order
    13407*).

[^2]: WARN Act, § 602(a).

[^3]: Public Alert and Warning System, Exec. Order No. 13407, 71 Fed.
    Reg. 36975 (Jun. 26, 2006) (*Executive Order 13407*). In Executive
    Order 13407, the President noted that it was the "policy of the
    United States to have an effective, reliable, integrated, flexible,
    and comprehensive system to alert and warn the American people in
    situations of war, terrorist attack, natural disaster, or other
    hazards to public safety and well-being . . .," and established
    certain obligations in this regard for the Department of Homeland
    Security, the National Oceanic & Atmospheric Administration (NOAA),
    and the FCC.

[^4]: *Executive Order 13407*, § 3(b)(iii).

[^5]: *See* 47 U.S.C. § 151.

[^6]: *See, e.g.,* Review of the Emergency Alert System, EB Docket No.
    04-296, *First Report and Order,* 20 FCC Rcd 18625 (2005) (EAS First
    Report and Order and Further Notice)

[^7]: *Id at* 18625, 18653.

[^8]: Cellular Telecommunications & Internet Association, Mid-Year 2007
    Top-Line Survey Results, *available at*
    <http://files.ctia.org/pdf/CTIA_Survey_Mid_Year_2007.pdf> (last
    visited on Mar. 18, 2008).

[^9]: *See supra,* n.1.

[^10]: WARN Act, § 603(a), (d).

[^11]: As required by the WARN Act, the CMSAAC consisted of
    representatives from state and local governments, federally
    recognized Indian tribes, representatives of the communications
    industry, including both wireless service providers and
    broadcasters, vendors and manufacturers and national organizations
    representing people with special needs. The Committee also included
    other qualified stakeholders such as representatives of the Federal
    Emergency Management Agency (FEMA) and NOAA. *See* Notice of
    Appointment of Members to the Commercial Mobile Service Alert
    Advisory Committee; Agenda for December 12, 2006 Meeting, *Public
    Notice*, 21FCC Rcd 14175 (PSHSB 2006).

[^12]: WARN Act, § 603(c).

[^13]: The CMSAAC held six meetings during which it received progress
    reports from its internal working groups and presentations from
    interested parties. On October 3, 2007, the Committee approved a set
    of recommendations and submitted them on October 12, 2007. In
    developing its recommendations, the CMSAAC consulted the National
    Institute of Standards and Technology (NIST), as required by section
    603(g) of the WARN Act.

[^14]: WARN Act, § 602(a).

[^15]: The Commercial Mobile Alert System, PS Docket No. 07-287, *Notice
    of Proposed Rulemaking*, 22 FCC Rcd 21975 (2007) (*CMAS NPRM*).

[^16]: In the *CMAS NPRM*, we also sought comment on issues related to
    other provisions of the WARN Act such as section 602(b) (requiring,
    among other things, that the Commission establish a mechanism for
    CMS providers to elect to participate in CMAS); section 602(c)
    (requiring the Commission to require noncommercial educational (NCE)
    broadcasters to install equipment to support geographically targeted
    (geo-targeting) alerts by CMS providers) and section 602(f)
    (authorizing the Commission to require testing of the CMAS). We will
    address these provisions of the WARN Act and related issues in
    subsequent Orders within the deadlines established by the statute.
    *See CMAS NPRM*, 22 FCC Rcd at 21976-21978, ¶ 5.

[^17]: A list of the parties commenting on the *CMAS NPRM* is attached
    at Appendix A.

[^18]: WARN Act, § 602(a).

[^19]: As required by section 602(a) of the WARN Act, we consulted the
    NIST in our adoption of technical rules.

[^20]: We note that the overwhelming majority of commenters support our
    adoption of the CMSAAC recommendations. *See*, *e.g.,* T-Mobile
    Comments at 2, 3G America Comments at 11, CTIA Comments at 19, TIA
    Comments at 10, AT&T Comments at 20, Ericsson, Inc. (Ericsson)
    Comments at 6, Rural Cellular Association Comments at 1-2.

[^21]: *See, e.g.*, Verizon Wireless Comments at 6, Verizon Wireless
    Reply Comments at 2-3, Rural Cellular Association (RCA) Comments at
    2-4, Alltel Comments at 2**.**

[^22]: *See* WARN Act, § 602(a).

[^23]: Had Congress, as some commenters suggest, intended to require
    that the Commission adopt the CMSAAC's recommendations "as is,"
    Congress would have simply said so. Moreover, the commenters'
    reading of the statute appears inconsistent with Congress' direction
    that both the CMSAAC and the Commission, separately, consult NIST.
    *Cf*, WARN Act § 602(a) and § 603(g). There would have been no need
    for the Commission to consult NIST again if, as the commenters
    suggest, Congress intended the Commission to simply adopt the
    CMSAAC's recommendations "as is."

[^24]: Ericsson Comments at 5.

[^25]: *See* CMSAAC recommendations, § 2.1, figure2-1 (CMAS Functional
    Reference Model).

[^26]: *See* CMSAAC recommendations, § 8.

[^27]: The Common Alerting Protocol (CAP) refers to Organization for the
    Advancement of Structured Information Standards (OASIS) Standard
    CAP-V1.1, October 2005.

[^28]: *See* CMSAAC recommendations, § 2.2.4

[^29]: Provisions have also been made for authorized alert originators
    to formulate and distribute alerts via the Alert Gateway in free
    text. *See e.g*., CMSAAC recommendations, § 5.3.2,.

[^30]: *See* CMSAAC recommendations, § 2.3.1.

[^31]: *See* CMSAAC recommendations, § 2.3.2.

[^32]: *See* CMSAAC recommendations, § 2.3.5.

[^33]: Each interface in the CMSAAC Reference Architecture represents a
    place where two elements in the Reference Architecture meet or
    connect. The "A" interface represents that connection between the
    alert initiator and the Alert Aggregator, the "B" interface
    represents the connection between the Alert Aggregator and Alert
    Gateway, the "C" interface represent the connection between the
    Alert Gateway and the CMS Provider Gateway, the "D" interface
    represents the connection between the CMS Provider Gateway and the
    CMS provider infrastructure, and the "E" interface represents the
    connection between the CMS provider infrastructure and the mobile
    device. For the purposes of this Order, the most important
    interfaces are the "C" and "E" interfaces. The "C" interface
    requires common protocols that will ensure that the alert
    information that flows from the Federal government administered
    Alert Gateway and the CMS providers is secure and accurate.
    Accordingly, both the Alert Gateway and CMS Provider Gateway must
    operate under a common set of protocols. The "E" interface will
    determine what information will appear on the mobile device. It is
    essential that the requirements for this interface allow accurate,
    timely, and accessible alerts for the mobile device user.

[^34]: *See* *CMAS NPRM,* 22 FCC Rcd at 21979-80, ¶¶ 12-13.

[^35]: *See* APTS Comments at 2-3. The Digital Emergency Alert System
    (DEAS) is a next generation alert and warning system that leverages
    the transition of television to DTV format.

[^36]: *See* CellCast Comments at 24.

[^37]: DataFM Comments at 10, NAB Comments at 2-3.

[^38]: *See* CMSAAC recommendations, § 2.2.

[^39]: *See* CMSAAC recommendations, § 2.2.2

[^40]: *CMAS NPRM*, 22 FCC Rcd at 21979-80, ¶¶ 12-13.

[^41]: *See generally*, Alltel Communications LLC (Alltel) Comments at
    4, AT&T Inc. (AT&T) Comments at 6, T-Mobile Comments at 7, and the
    California Public Utilities Commission (CAPUC) Comments at 6,7. *But
    see, e.g.,* Ken Post Comments at 2 (CMAS should be based on a shred
    authority system as envisioned by the National Incident Management
    System), National Association of Broadcasters (NAB) Comments at 2-3
    (a government-run aggregator creates a complex single system that
    has the potential to be a single point of failure), CellCast
    Comments at 7-9 (aggregator is not required for CMAS implementation,
    either at the National, State, or local levels).

[^42]: Alltel Comments at 4.

[^43]: *See* CMSAAC recommendations, §§ 2.3.5 and 7.

[^44]: As noted, *infra* at ¶¶ 34-41 the CMSAAC recommendations and this
    First Report and Order consistently conclude that the requirements
    for the CMAS should be technologically neutral. APTS's arguments
    regarding equipment are more appropriately addressed in the order
    that addresses section 602(c) of the WARN Act.

[^45]: AT&T Comments at 6 ("it is critical to the success... that a
    single Government Entity serve as the alert aggregator and
    gateway... whether it assumes this role directly or via a third
    party contractor "); CTIA Comments at 2 (Commission adoption of the
    CMSAAC recommendations as submitted will encourage the highest level
    of participation); T-Mobile Comments at 15, 16 (Centralization is
    key to the proper functioning of a CMAS, and that it must be managed
    by the federal government. Without the centralized system,
    participation at all these levels could result in chaos).

[^46]: *See* CMSAAC recommendations at 71. The CMSAAC recommended that
    CMAS system reliability meet "telecom standards for highly reliable
    systems," which generally implies the use of redundant elements
    where single points of failure would otherwise exist.

[^47]: Based on the CMAS alert volumes anticipated by the CMSAAC in
    section 11 of the CMSAAC recommendations, we agree with the CMSAAC's
    view that developing the technology for processing alerts according
    to the CMSAAC proposed timeline will not overburden the
    aggregator/gateway performance.

[^48]: *See* FEMA Comments at 2 (stating that although it supports the
    CMSAAC's recommendations, it "\[do\[es\] not have the authority
    during non-emergency periods to develop, implement, operate or
    maintain elements of the CMAS that regard alerts, warnings or
    notifications originated by state and local authorities such as the
    Aggregator and Gateway functions of the Trust Model of the CMAS,
    under \[its\] current statutory authority.")

[^49]: FEMA administers the Emergency Alert System (EAS) while NOAA
    operates the NOAA Weather Radio (NWR). *See*
    <http://www.weather.gov/nwr/> (last viewed on April 7, 2008). The
    respective roles of the Commission, FEMA, and NOAA are based on a
    1981 Memorandum of Understanding, *see State and Local Emergency
    Broadcasting System* (EBS) *Memorandum of Understanding Among the
    Federal Emergency Management Agency* (FEMA), *Federal Communications
    Commission* (Commission), *and the National Oceanic and Atmospheric
    Administration* (NOAA) (Approved by National Industry Advisory
    Committee (NIAC) on April 21, 1982), a 1984 Executive Order,
    *Assignment of National Security and Emergency Preparedness
    Telecommunications Functions*, Exec. Order No. 12,472, 49 Fed. Reg.
    13,471 (1984), and a 1995 Presidential Statement of Requirements,
    *see Presidential Communications with the General Public During
    Periods of National Emergency,* The White House (September 15,
    1995).

[^50]: While the FCC could perform this role, additional funding to
    support such an undertaking would likely be necessary. We note that
    unlike the FCC, DHS and the Department of Commerce have authority
    under the WARN Act to borrow up to \$106 million against Digital
    Television (DTV) transition revenues in order to fulfill their
    obligations under the statute. *See* WARN Act, § 606(c). It is also
    our understanding that FEMA has funding for its Integrated Public
    Alert and Warning System.

[^51]: Executive Order 13407, § 1.

[^52]: FEMA administers the Emergency Alert System (EAS) while NOAA
    operates the NOAA Weather Radio (NWR). *See*
    <http://www.weather.gov/nwr/> (last viewed on April 7, 2008). The
    respective roles of the Commission, FEMA, and NOAA are based on a
    1981 Memorandum of Understanding, *see State and Local Emergency
    Broadcasting System* (EBS) *Memorandum of Understanding Among the
    Federal Emergency Management Agency* (FEMA), *Federal Communications
    Commission* (Commission), *and the National Oceanic and Atmospheric
    Administration* (NOAA) (Approved by National Industry Advisory
    Committee (NIAC) on April 21, 1982), a 1984 Executive Order,
    *Assignment of National Security and Emergency Preparedness
    Telecommunications Functions*, Exec. Order No. 12,472, 49 Fed. Reg.
    13,471 (1984), and a 1995 Presidential Statement of Requirements,
    *see Presidential Communications with the General Public During
    Periods of National Emergency,* The White House (September 15,
    1995).

[^53]: *See* FEMA Comments at 2.

[^54]: Accordingly, the compliance date for the rules we adopt today is
    tied to the announcement of an entity to fulfill these functions.
    The absence of an aggregator/gateway, however, will have no impact
    on a CMS provider's obligation under the WARN Act to elect whether
    or not it intends to transmit emergency alerts within 30 days of the
    Commission's issuance of rules required under section 602(b). *See*
    WARN Act, § 602(b).

[^55]: A complete list of the required CMS infrastructure functions is
    set forth in the rules in Appendix C.

[^56]: The C interface is a secure interface over which alerts can be
    passed from the Aggregator/Gateway to the CMS Provider Gateway.
    Under our rules, the CMS provider must: (1) provide information for
    the authentication and validation of actions across the interface;
    (2) be able to receive new, updated or cancelled wireless alert
    messages from the Alert Gateway in a format that is suitable for the
    mobile devices and the wireless alert deliver technology or
    technologies implemented by the CMS provider; and (3) acknowledge
    the receipt of new, updated or cancelled wireless alert messages.

[^57]: A complete list of the CMS Provider Gateway's required functions
    is set forth in the rules in Appendix C.

[^58]: Interstate Wireless supports the CMSAAC recommended reference
    architecture, but notes that the cost of building and maintaining a
    CMS Provider Gateway would be more than it and other similarly
    situated Small Business CMS providers could afford and still be able
    to provide the alert service to the public without cost.
    Accordingly, Interstate Wireless requests that the Federal
    Government either provide the proper software and reception
    equipment for the CMS Provider Gateways, or provide grants to the
    Small Business CMS providers to purchase, install, and maintain the
    equipment themselves. Interstate Wireless Comments at 6. We
    acknowledge the concern of Interstate Wireless, but note that
    questions of funding are not addressed by section 602(a) of the WARN
    Act, and thus are outside of the scope of this order.

[^59]: CMSAAC recommendations, § 1.1.1*.*

[^60]: *See infra* ¶¶ 57-67.

[^61]: CMSAAC recommendations, § 7.3.

[^62]: *See* Functional Reference Model Diagram, *supra* ¶ 10*.*

[^63]: No commenter objected to this recommendation.

[^64]: For this reason, we conclude that our decision is consistent with
    section 602(a) of the WARN Act which requires that we adopt
    technical requirements "necessary" for CMS alerting capability. WARN
    Act, § 602(a).

[^65]: *See infra,* ¶¶ 26-30 (discussion of CMAS Alert Categories).

[^66]: *See* CMSAAC recommendations, § 2.2.4.2.

[^67]: *See* CMSAAC recommendations, § 2.2.4.2 and Table 2.1.

[^68]: *See* CMSAAC recommendations, § 10.

[^69]: We note that the Alliance for Telecommunications Industry
    Solutions (ATIS) and Telecommunications Industry Association (TIA)
    are beginning to engage in standards setting related to the CMAS.
    *See* ATIS Comments at 4-5.

[^70]: WARN Act, § 602(b)(2)(e).

[^71]: *CMAS NPRM*, 22 FCC Rcd at 21981, ¶16.

[^72]: *Id.*

[^73]: CMSAAC recommendations at § 5.1. *See also* CAPUC Comments at
    10-11.

[^74]: Alert Systems Comments at 16 (urging more than three
    classification levels, claiming disaster managers need the ability
    to dispatch road closure and other community relevant information).

[^75]: *See* MetroPCS Comments at 3 (noting that if too many alert
    messages are transmitted, users may ignore them); T-Mobile Comments
    at 10 ("\[s\]ubscribers will be more likely to opt out of CMAS
    altogether if their devices are inundated with minor alerts").

[^76]: WARN Act, § 602(b)(2)(e).

[^77]: *Executive Order 13407*, § 2(a)(x).

[^78]: *See* CMSAAC recommendations, § 2.3.2 (CMS providers will
    prioritize Presidential alerts).

[^79]: *See infra* ¶¶ 82-83.

[^80]: CMSAAC recommendations, § 5.3.3.

[^81]: *But cf.* CellCast Comments at 29 (opposing adoption of alert
    classes).

[^82]: *See* CAP-V1.1 at 16.

[^83]: *See* CAP-V1.1 at 17.

[^84]: *Id.*

[^85]: *See* *supra*, n.20.

[^86]: T-Mobile Comments at 9-10.

[^87]: *See, e.g.*, Acision Comments at 6-7 (supporting the inclusion of
    AMBER alerts to, among other things, maintain public awareness of
    the CMAS). We note that on April 30, 2003, President George W. Bush
    signed the Prosecutorial Remedies and Other Tools to end the
    Exploitation of Children Today (PROTECT) Act of 2003 (Pub. L. No.
    108-21,117 Stat 650 (Apr. 20, 2003)) into law. Building on the steps
    already taken by the Federal Government to support AMBER Alerts,
    this Act codified the national coordination of state and local
    programs, including the development of guidance for issuance and
    dissemination of AMBER Alerts and the appointment of a national
    AMBER Alert Coordinator.

[^88]: A Family Abduction (FA) involves an abductor who is a family
    member of the abducted child such as a parent, aunt, grandfather, or
    stepfather. *See* http://www.amberalert.gov/statistics.htm.

[^89]: A Nonfamily Abduction (NFA) involves an abductor unrelated to the
    abducted child, either someone unknown to the child and/or the
    child's family or an acquaintance/friend of the child and/or the
    child's family. *Id.*

[^90]: A Lost, Injured, or Otherwise Missing (LIM) involves a case where
    the circumstances of the child's disappearance are unknown. *Id.*

[^91]: An Endangered Runaway (ERU) involves a missing child who is
    believed to have run away and in imminent danger. *Id.*

[^92]: Localities generally establish AMBER plans based on the U.S.
    Department of Justice's five criteria that should be met before an
    alert is activated: (1) law enforcement confirms a child has been
    abducted; (2) the child is 17 years or younger; (3) law enforcement
    believes the child is in imminent danger of serious bodily harm or
    death; (4) there is enough descriptive information about the victim
    and the abduction to believe an immediate broadcast alert will help;
    and (5) the child's name and other data have been entered into the
    National Crime Information Center. *See*
    <http://www.amberalert.gov/>.

[^93]: *See* How Wireless AMBER Alerts™ Are Sent, available at
    <http://wirelessamberalerts.adcouncil.org/howwirelessamberalertswork.htm>.

[^94]: *See* National Center for Missing & Exploited Children, 2006
    *AMBER-Alert Report* at 7.

[^95]: In 2006, 11 AMBER Alerts were extended beyond the limits of the
    state where the alert first originated. *Id*. at 8. Eight alerts
    were extended to one additional state, and three alerts were
    extended to two states each. *Id.*

[^96]: Nine (9) children were recovered deceased, and, as of April 21,
    2007, 10 cases remained active with 11 children still missing. *Id.*

[^97]: CMSSAC recommendations, §5.1.

[^98]: SouthernLINC Comments at 4-6.

[^99]: *See* Amendment of the Commission\'s Rules to Permit Flexible
    Service Offerings in the Commercial Mobile Radio Services, WT Docket
    No. 96-6, *Second Report and Order and Order on Reconsideration*, 15
    FCC Rcd 14680 (2000).

[^100]: WARN Act, § 602(a).

[^101]: ReFLEX is a wireless network protocol developed by Motorola
    which is used for two-way paging. Narrowband PCS carriers use the
    ReFLEX technology protocol, which can transmit data at speeds
    ranging from 3.2 to 25 kbps. *See Tenth CMRS Competition Report*, 20
    FCC Rcd at 15955, ¶ 124. For more information regarding ReFLEX,
    *see* http://usamobility.com/pdf/ReFLEX2.pdf. For more information
    regarding POCSAG, *see*
    http://www.wireless.per.nl/reference/chaptr01/dtmmsyst/paging.htm.

[^102]: *See* AAPC Comments at 7.

[^103]: *See, e.g*., Sprint Nextel Comments at 8-9 (noting that certain
    industry standardization processes must be completed before CMAS
    deployment).

[^104]: According to the CMSAAC, point-to-point technologies may
    experience delivery delays, network congestion, and lack
    geo-targeting capabilities because alerts are targeted to phone
    numbers instead of a specific alert area. *See* CMSAAC
    recommendations at § 5.2.

[^105]: SMS enables the transmission of alphanumeric messages between
    mobile subscribers and external systems such as electronic mail,
    paging, and voice mail systems. For a more complete description,
    *see* <http://electronics.howstuffworks.com/sms1.htm> and
    http://www.mobilein.com/SMS_tutorial.pdf.

[^106]: The District of Columbia and many of its neighboring
    jurisdictions, for example, have such emergency alert systems. *See*
    [http://textalert.ema.dc.gov](http://textalert.ema.dc.gov/) (Alert
    DC); <http://www.fairfaxcounty.gov/cean> (Fairfax County, VA);
    [http://alert.montgomerycountymd.gov](http://alert.montgomerycountymd.gov/)
    (Montgomery County, MD).

[^107]: Many CMS providers are successfully using SMS today to transmit
    geographically specific AMBER Alerts to interested subscribers. The
    wireless AMBER alert system notifies wireless customers who have
    elected to receive the service of missing children alerts.
    Information regarding the system is available at
    <http://www.wirelessfoundation.org/amber>. Thirty-two wireless
    carriers currently participate in the system. *See*
    <http://wirelessamberalerts.adcouncil.org/partners.htm>.

[^108]: CMSAAC recommendations, § 5.2. Information regarding MediaFLO
    technology is available at
    <http://www.qualcomm.com/mediaflo/about_us/index.shtml>. Information
    regarding DVB-H technology is available at http://
    [www.dvb-h.org/technology.htm](http://www.dvb-h.org/technology.htm).

[^109]: CMSAAC recommendations, § 5.2.

[^110]: *See, e.g.,* Comments of Data-FM at 7-8, Sheriff of Jefferson
    County, Louisiana; Florida Association of Broadcasters, Mississippi
    Office of Homeland Security, Mississippi Office of Emergency
    Management.

[^111]: *See* CMSAAC recommendations at 47-48.

[^112]: *See e.g.,* AT&T Reply Comments at 11-12.

[^113]: CMS providers have discretion to use these technologies so long
    as they are able to transmit emergency alerts in a manner consistent
    with the rules we adopt today.

[^114]: CMSAAC recommendations, § 5.1.

[^115]: *Id.*

[^116]: *Id.*

[^117]: WARN Act, § 602(a).

[^118]: CMSAAC recommendations**,** § 5.2.4**.**

[^119]: CMSAAC recommendations**,** § 5.1

[^120]: *Id.*

[^121]: WARN Act, § 602(b).

[^122]: CMSAAC recommendations, § 5.3.1.

[^123]: *Id.*

[^124]: *Id.*

[^125]: *CMAS NPRM*, 22 FCC Rcd at 21981, ¶18.

[^126]: T-Mobile Comments at 18.

[^127]: Purple Tree Technologies Comments at 10.

[^128]: Alert Systems Comments at 16-17.

[^129]: URL is an acronym for Uniform Resource Locator and is a
    reference (an address) to a resource on the Internet. A URL has two
    main components: a protocol identifier and a resource name, which
    are separated by a colon and two forward slashes. The protocol
    identifier indicates the name of the protocol to be used to obtain
    the resource, such as HTTP (Hypertext Transfer Protocol). HTTP is
    just one of many protocols used to access different types of
    resources on the Internet. Other protocols include File Transfer
    Protocol (FTP), Gopher, File, and News. Additional information
    regarding URLs is available at
    <http://java.sun.com/docs/books/tutorial/networking/urls/index.html>.

[^130]: *CMAS NPRM*, 22 FCC Rcd at 21981-82, ¶20.

[^131]: *See* CMSAAC recommendations, § 5.3.2.1.

[^132]: *See, e.g.*, CAPUC Comments at 12.

[^133]: AT&T Comments at 8; T-Mobile Comments at 19-20 (opposing
    inclusion of URLs, telephone numbers because "such information could
    cause customers to flood the wireless network resulting in crippling
    network congestion)"

[^134]: *See* Alltel Reply Comments at 3 ("network congestion exists
    during emergencies today and would be made worse by inserting a
    phone number or URL to encourage people to initiate more calls');
    RCA Reply Comments at 7 (inclusion of URLs or telephone numbers
    could make "it difficult or impossible for anyone to complete a
    critical telephone call" and possibly "tak\[e\] the entire wireless
    network down").

[^135]: *CMAS NPRM*, 22 FCC Rcd at 21981, ¶19; CMSAAC recommendations, §
    5.3.2.

[^136]: *See* CMSAAC recommendations, § 5.3.2.

[^137]: *CMAS NPRM*, 22 FCC Rcd at 21981, ¶19; CMSAAC recommendations, §
    5.3.3.

[^138]: *See* AAPC Comments at 5 ("urg\[ing\] the Commission to accept
    the recommendations as presented").

[^139]: AT&T Comments at 9.

[^140]: CellCast Comments at 36.

[^141]: CMSAAC recommendations, § 5.3.2.

[^142]: *See* CMSAAC recommendations, § 5.3.2.1.

[^143]: The only exception to this conclusion is the Presidential alert,
    which will be transmitted regardless of content provided it
    satisfies the 90 character limit.

[^144]: *Id.*

[^145]: CMSAAC recommendations, § 5.3.3.

[^146]: *Id.*

[^147]: *Id.*

[^148]: CMSAAC recommendations, § 5.4.

[^149]: WARN Act, § 604(b)(2).

[^150]: The CMSAAC recommends that we encourage DHS to establish a
    program under section 604 to develop geo-targeting technologies.
    CMSAAC Recommendations, § 5.4.

[^151]: *See, e.g.,* Alltel Comments at 4-5.

[^152]: T-Mobile Comments at 17*.*

[^153]: *CMAS NPRM*, 22 FCC Rcd at 21982 ¶¶ 21-22.

[^154]: CMSAAC recommendations, § 5.4.

[^155]: *Id.* Systems used by Alert Initiators may allow them to define
    an alert area on a map. For example, the defined alert area could
    include the projected path of a tornado or an event that encompasses
    a portion of an urban area.

[^156]: *Id.* at § 5.4. The CMSSAC recommended that if a geocode,
    polygon, or circle is not transmitted with a non-presidential alert,
    the "Alert Gateway" should reject the message and return an error to
    the originator. *Id*. at App. B, § 10.3.2.22.

[^157]: CMSAAC Recommendations, § 10.3.2.

[^158]: Alert Systems Comments at 17, 18.

[^159]: Purple Tree Comments at 2, 11. We reject Purple Tree
    Technologies' suggestion that polygon information should have
    priority over geocode information, which would be contrary to the
    CMSAAC Recommendations at § 5.3.1.

[^160]: Acision Comments at 6-7; CellCast Comments at 38-39. Westchester
    County, New York also supports the use of cell broadcast technology
    for sub-county targeting. *See* Westchester County Comments at 2, 3.

[^161]: DataFM Comments at 12.

[^162]: NENA Comments at 2.

[^163]: *Id.*

[^164]: CAPUC Comments at 13-15. *But see* NTCA Reply Comments at 4
    ("The Commission should decline to follow the CAPUC's suggestion and
    should, instead, adhere to the CMSAAC's recommendation that
    emergency service alerts be geo-targeted and delivered no lower than
    the county-wide size area.").

[^165]: *See* Census 2000 U.S. Gazetteer Files, available at
    <http://www.census.gov/geo/www/gazetteer/places2k.html>.

[^166]: We also note that New York City, which did not file comments,
    previously expressed concern that alerts should be targeted more
    precisely than county-level. *See CMAS NPRM*, 22 FCC Rcd at 21982,
    n.40.

[^167]: CTIA Comments at 7, 8; TIA Comments at 3, 4; 3G Americas
    Comments at 9.

[^168]: T-Mobile Comments at 17.

[^169]: Alltel Comments at 4-5.

[^170]: MetroPCS Comments at 4-5.

[^171]: NTCA Reply Comments at 4.

[^172]: AAPC Comments at 7.

[^173]: *See, e.g.,* Purple Tree Comments at 11, CAPUC Comments at
    13-15, NENA Comments at 2, Alert Systems Comments at 17-18*.*

[^174]: *See generally* Acision Comments at 6-7; Alert Systems Comments
    at 17, 18; CellCast Comments at 38-39; DataFM Comments at 12; Purple
    Tree Comments at 2, 11.

[^175]: CMSAAC Recommendations, § 5.4.

[^176]: WARN Act, § 603(b)(3)(f).

[^177]: WARN Act, § 603(c)(7).

[^178]: CMSAAC recommendations, § 5.5.2.1.

[^179]: *Id.*

[^180]: *Id.*

[^181]: *Id.*

[^182]: *Id.*

[^183]: *Id.*

[^184]: *CMAS NPRM*, 22 FCC Rcd at 21982-83, ¶ 23.

[^185]: *Id.*

[^186]: *Id.*

[^187]: AT&T Comments at 15.

[^188]: Alert Systems Comments at 18.

[^189]: *Id.*

[^190]: Wireless RERC Comments at 11.

[^191]: *Id.* at 11-12. Wireless RERC also states that CMS providers
    should notify those subscribers whose mobile devices require
    upgrading to support CMAS. *Id.* at 12.

[^192]: AAPC Comments at 7-8.

[^193]: *Id.* at 18.

[^194]: DataFM Comments at 12-13.

[^195]: MetroPCS Comments, *citing* 47 C.F.R. § 20.19.

[^196]: CellCast Comments at 43-44.

[^197]: The CMSAAC recommendations state that "\[a\] unique vibration
    cadence (if supported by the mobile device) should be provided as
    well as a unique audio attention signal." CMSAAC Recommendations at
    § 5.5.2. To the extent that this language implies that CMAS-capable
    mobile devices do not have to supply a unique vibration cadence, we
    disagree. Rather, we believe that full access by people with hearing
    disabilities requires vibration capability. Given that most current
    mobile handsets are capable of programming dedicated audio and
    vibration ring tones, we do not believe that this requirement
    represents a significant burden for CMS providers or is inconsistent
    with the WARN Act.

[^198]: CMSAAC recommendations, § 7.2.

[^199]: *Id.*

[^200]: We agree with the CMSAAC that CMAS compliant mobile devices may
    include the capability to mute either or both of these features so
    that they will not be activated upon receipt of an alert. CMSAAC
    recommendations, § 7.3.

[^201]: *See* CMSAAC recommendations, § 5.5.2.3.

[^202]: *Id.,* citing Tips for Making Print More Readable, American
    Foundation for the Blind, available at
    <http://www.afb.org/Section.asp?SectionID=40&TopicID=200&DocumentID=210>.

[^203]: MetroPCS Comments at 5, citing 47 C.F.R. § 20.19.

[^204]: CellCast Comments at 43-44.

[^205]: CMSAAC recommendations, § 5.5.2.3.

[^206]: Information regarding TTS is
    <http://www.research.att.com/~ttsweb/tts/faq.php#TechWhat>.

[^207]: *See* CMSAAC recommendations, § 5.6.

[^208]: *See infra* ¶ 80.

[^209]: *See* CMSAAC recommendations, § 5.6.

[^210]: WARN Act, § 603(c)(4).

[^211]: *CMAS NPRM*, 22 FCC Rcd at 21983, ¶ 24.

[^212]: *Id.*

[^213]: CMSAAC recommendations, § 5.7.

[^214]: *Id.*

[^215]: *Id.*

[^216]: *Id.*

[^217]: *Id.*

[^218]: CAPUC Comments at 19.

[^219]: *Id.*, n.16.

[^220]: *Id.* at 20.

[^221]: *See id.* at 19.

[^222]: CellCast Comments at 46.

[^223]: CellCast Reply Comments at 20.

[^224]: CellCast Comments at 47-48.

[^225]: CellCast Reply Comments at 22-23.

[^226]: One2many Comments at 7.

[^227]: *Id.*; *see also* DataFM Comments at 13.

[^228]: CTIA Comments at 9-10; CTIA Reply Comments at 7-9.

[^229]: Alltel Comments at 5-6.

[^230]: *Id.* at 5.

[^231]: *Id.*; Alltel Reply Comments at 4; *see also* TIA Comments at
    8-10.

[^232]: MetroPCS Comments at 5; *cf.* Alert Systems Comments at 18-19.
    Alert Systems argues that regulatory mechanisms for alternate
    languages are unnecessary because the system's development is really
    only limited by the font sets of the receiving devices and by the
    ability of disaster management agencies to prepare warnings in other
    languages. *Id.*

[^233]: AAPC Comments at 8.

[^234]: T-Mobile Comments at 13-14.

[^235]: AT&T Comments at 15-16; CTIA Reply Comments at 7-9.

[^236]: *Id.*

[^237]: Wireless RERC Comments at 12. T-Mobile, however, criticizes this
    suggestion in its reply comments, noting that such an existing
    technology is not identified in the record, and that it is against
    the CMSAAC's goal of uniform, error-free messaging to allow multiple
    carriers to create their own versions of alerts in various
    languages. T-Mobile Reply Comments at 7-8. T-Mobile contends that
    the only means for transmitting multi-language alerts is for the
    Alert Aggregator to send messages in multiple languages, as the
    CMSAAC recommends. *Id.* at 8.

[^238]: CMSAAC recommendations, § 5.9.

[^239]: WARN Act, § 602(a).

[^240]: *Executive Order 13407*, § 3(b)(iii).

[^241]: Reexamination of Roaming Obligations of Commercial Mobile Radio
    Service Providers, WT 05-265, *Report and Order and Further Notice
    of Proposed Rulemaking*, 22 FCC Rcd 15817, 15855, ¶76 (2007). We
    note that the scope of the Commission's automatic roaming
    requirement is applicable to CMRS carriers "if such carriers offer
    real-time two-way switched voice or data service that is
    interconnected with the public switched network and utilizes an
    in-network switching facility that enables the carrier to re-use
    frequencies and accomplish seamless hand-offs of subscriber calls."
    *See* 47 C.F.R. § 20.12(a)(2). The automatic roaming requirement is
    also applicable to the provision of push-to-talk and text-messaging
    service by CMRS carriers. *Id.*

[^242]: We will defer consideration of any subscriber notification
    requirements related to CMAS roaming to our forthcoming order
    addressing the WARN Act's requirements under section 602(b) for CMAS
    provider elections to support CMAS.

[^243]: CMSAAC recommendations, § 7.3.

[^244]: CMSAAC recommendations, § 6 (Service Profiles).

[^245]: *See*, *e.g.* Purple Tree Technology Comments at 9, AT&T
    Comments at 10.

[^246]: *CMAS NPRM*, 22 FCC Rcd at 21980-81, ¶15.

[^247]: AT&T Comments at 8

[^248]: Motorola Comments at 3.

[^249]: AAPC Comments at 5.

[^250]: *See* CellCast Comments at 28.

[^251]: *See* Kendall Post of Alert Systems, Inc. at 15.

[^252]: Metro PCS Comments at 3.

[^253]: Wireless RERC Comments at 8.

[^254]: The only exception to this is the Presidential alert, which will
    be transmitted provided it meets the 90-character limit.

[^255]: Wireless RERC Comments at 9.

[^256]: *See* CMSAAC recommendations, § 8.3

[^257]: Purple Tree Technologies Comments at 6.

[^258]: *See* Verizon reply Comments at 5.

[^259]: *Id.*

[^260]: *See* *supra*, ¶¶ 15-18*.*

[^261]: CMSAAC recommendations, § 12.2.

[^262]: *See* n.20, *supra.*

[^263]: FEMA Comments at 2.

[^264]: We state, *infra* at ¶ 94, that this Report and Order shall
    become effective 30 days after publication in the Federal Register
    except that the new information collection requirements contained in
    these rules will not become effective prior to OMB approval.
    However, the rules themselves specifically state that electing CMS
    providers must comply no later than 10 months from the date of
    announcement of an entity to serve the Alert Aggregator and Alert
    Gateway functions. This is similar to Commission's adoption of rules
    requiring all EAS Participants to be able to receive CAP formatted
    EAS alerts no later than 180 days after FEMA publishes the technical
    standards and requirements for such FEMA transmissions. *See* Review
    of the Emergency Alert System, 22 FCC Rcd 13275, 13310 and Appendix
    C; *see also* 47 C.F.R. § 11.56. That Order also became effective 30
    days after publication in the Federal Register, except that new or
    modified information collections did not become effective prior to
    OMB approval.

[^265]: We note that our adoption of an effective date and compliance
    deadline have no impact on the WARN Act\'s requirement that CMS
    providers notify the Commission whether or not they intend to
    transmit emergency alerts within 30 days of the Commission\'s
    issuance of rules required under section 602(b). *See* WARN Act, §
    602(b).

[^266]: *See supra* ¶ 95.

[^267]: *See* 5 U.S.C. § 603. The RFA, *see* 5 U.S.C. §§ 601-612, has
    been amended by the Small Business Regulatory Enforcement Fairness
    Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857
    (1996).

[^268]: *See* 5 U.S.C. § 603(a).

[^269]: 73 FR 546-01 (January 3, 2008).

[^270]: WARN Act § 602(a).

[^271]: As the CMAS First Report and Order indicates in note 16, supra,
    the Commission will address these other provisions of the WARN Act
    and related issues in subsequent Orders within the deadlines
    established by the statute.

[^272]: Interstate Wireless Comments at 1.

[^273]: *See CMAS First Report and Order,* n.58, *infra*

[^274]: 5 U.S.C. § 603(b).

[^275]: 5 U.S.C. § 601(6).

[^276]: 5 U.S.C. § 601(3) (incorporating by reference the definition of
    "small-business concern" in the Small Business Act, 15 U.S.C. §
    632). Pursuant to 5 U.S.C. § 601(3), the statutory definition of a
    small business applies "unless an agency, after consultation with
    the Office of Advocacy of the Small Business Administration and
    after opportunity for public comment, establishes one or more
    definitions of such term which are appropriate to the activities of
    the agency and publishes such definition(s) in the Federal
    Register." 5 U.S.C. § 601(3).

[^277]: 15 U.S.C. § 632.

[^278]: 13 C.F.R. § 121.201, NAICS code 517210.

[^279]: 13 C.F.R. § 121.201, NAICS codes 517211, 517212.

[^280]: U.S. Census Bureau, 2002 Economic Census, Subject Series:
    Information, "Establishment and Firm Size (Including Legal Form of
    Organization," Table 5, NAICS code 517211 (issued Nov. 2005).

[^281]: *Id.* The census data do not provide a more precise estimate of
    the number of firms that have employment of 1,500 or fewer
    employees; the largest category provided is for firms with "1000
    employees or more."

[^282]: U.S. Census Bureau, 2002 Economic Census, Subject Series:
    Information, "Establishment and Firm Size (Including Legal Form of
    Organization," Table 5, NAICS code 517212 (issued Nov. 2005).

[^283]: *Id.* The census data do not provide a more precise estimate of
    the number of firms that have employment of 1,500 or fewer
    employees; the largest category provided is for firms with "1000
    employees or more."

[^284]: 13 C.F.R. § 121.201, North American Industry Classification
    System (NAICS) code 517210.

[^285]: *Id.*

[^286]: 13 C.F.R. § 121.201, NAICS code 517210.

[^287]: 13 C.F.R. § 121.201, NAICS codes 517211, 517212.

[^288]: *See* Amendment of Parts 20 and 24 of the Commission's Rules --
    Broadband PCS Competitive Bidding and the Commercial Mobile Radio
    Service Spectrum Cap, Report and Order, 11 FCC Rcd 7824, 7850-7852
    ¶¶ 57-60 (1996); *see also* 47 C.F.R. § 24.720(b).

[^289]: *See* Amendment of Parts 20 and 24 of the Commission's Rules --
    Broadband PCS Competitive Bidding and the Commercial Mobile Radio
    Service Spectrum Cap, Report and Order, 11 FCC Rcd 7824, 7852 ¶ 60.

[^290]: *See* Letter to Amy Zoslov, Chief, Auctions and Industry
    Analysis Division, Wireless Telecommunications Bureau, Federal
    Communications Commission, from Aida Alvarez, Administrator, Small
    Business Administration, dated December 2, 1998.

[^291]: FCC News, "Broadband PCS, D, E and F Block Auction Closes," No.
    71744 (rel. January 14, 1997).

[^292]: *See* "C, D, E, and F Block Broadband PCS Auction Closes,"
    Public Notice, 14 FCC Rcd 6688 (WTB 1999).

[^293]: *See* "C and F Block Broadband PCS Auction Closes; Winning
    Bidders Announced," Public Notice, 16 FCC Rcd 2339 (2001).

[^294]: Implementation of section 309(j) of the Communications Act --
    Competitive Bidding Narrowband PCS, Third Memorandum Opinion and
    Order and Further Notice of Proposed Rulemaking, 10 FCC Rcd 175, 196
    ¶ 46 (1994).

[^295]: *See* "Announcing the High Bidders in the Auction of ten
    Nationwide Narrowband PCS Licenses, Winning Bids Total
    \$617,006,674," Public Notice, PNWL 94-004 (rel. Aug. 2, 1994);
    "Announcing the High Bidders in the Auction of 30 Regional
    Narrowband PCS Licenses; Winning Bids Total \$490,901,787," Public
    Notice, PNWL 94-27 (rel. Nov. 9, 1994).

[^296]: Amendment of the Commission's Rules to Establish New Personal
    Communications Services, Narrowband PCS, Second Report and Order and
    Second Further Notice of Proposed Rule Making, 15 FCC Rcd 10456,
    10476 ¶ 40 (2000).

[^297]: *Id.*

[^298]: *Id.*

[^299]: *See* Letter to Amy Zoslov, Chief, Auctions and Industry
    Analysis Division, Wireless Telecommunications Bureau, Federal
    Communications Commission, from Aida Alvarez, Administrator, Small
    Business Administration, dated December 2, 1998.

[^300]: *See* "Narrowband PCS Auction Closes," Public Notice, 16 FCC Rcd
    18663 (WTB 2001).

[^301]: Amendment of the Commission's Rules to Establish Part 27, the
    Wireless Communications Service (WCS), Report and Order, 12 FCC Rcd
    10785, 10879 ¶ 194 (1997).

[^302]: *See* Letter to Amy Zoslov, Chief, Auctions and Industry
    Analysis Division, Wireless Telecommunications Bureau, Federal
    Communications Commission, from Aida Alvarez, Administrator, Small
    Business Administration, dated December 2, 1998.

[^303]: *See* Service Rules for the 746-764 MHz Bands, and Revisions to
    Part 27 of the Commission's Rules, Second Report and Order, 15 FCC
    Rcd 5299 (2000).

[^304]: *Id.* at 5343 ¶ 108.

[^305]: *Id.*

[^306]: *Id.* At 5343 ¶ 108 n.246 (for the 746-764 MHz and 776-704 MHz
    bands, the Commission is exempt from 15 U.S.C. § 632, which requires
    Federal agencies to obtain Small Business Administration approval
    before adopting small business size standards).

[^307]: *See* "700 MHz Guard Bands Auction Closes: Winning Bidders
    Announced," Public Notice, 15 FCC Rcd 18026 (2000).

[^308]: *See* "700 MHz Guard Bands Auctions Closes: Winning Bidders
    Announced," Public Notice, 16 FCC Rcd 4590 (WTB 2001).

[^309]: *See* In the Matter of Service Rules for the 698-746, 747-762
    and 777-792 MHz Bands, WT Docket 06-150, Second Report and Order, 22
    FCC Rcd 15289, 15339-15344 ¶¶ 118-134 (2007) (700 MHz Second Report
    and Order).

[^310]: *Id.*

[^311]: *See* Auction of 700 MHz Band Licenses Scheduled for January 24,
    2008, AU Docket No. 07-157, Notice and Filing Requirements, Minimum
    Opening Bids, Reserve Prices, Upfront Payments, and Other Procedures
    for Auctions 73 and 76, DA 07-4171 at ¶ 70 (WTB rel. Oct. 5, 2007);
    Reallocation and Service Rules for the 698-746 MHz Spectrum Band
    (Television Channels 52-59), Report and Order, 17 FCC Rcd 1022,
    1087-88 (2002).

[^312]: *Id.* at 1088.

[^313]: *See* Letter to Thomas Sugrue, Chief, Wireless
    Telecommunications Bureau, Federal Communications Commission, from
    Aida Alvarez, Administrator, Small Business Administration, dated
    August 10, 1999.

[^314]: *See* "Lower 700 MHz Band Auction Closes," Public Notice, 17 FCC
    Rcd 17272 (WTB 2002).

[^315]: *See* "Lower 700 MHz Band Auction Closes," Public Notice, 18 FCC
    Rcd 11873 (WTB 2003).

[^316]: *Id.*

[^317]: Service Rules for Advanced Wireless Services in the 1.7 GHz and
    2.1 GHz Bands, WT Docket No. 02-353, Report and Order, 18 FCC Rcd
    25162 (2003) (AWS-1 Report and Order).

[^318]: *See* Implementation of section 309(j) of the Communications Act
    \-- Competitive Bidding, Third Memorandum Opinion and Order and
    Further Notice of Proposed Rulemaking, 10 FCC Rcd 175, 196 (1995);
    Implementation of section 309(j) of the Communications Act \--
    Competitive Bidding, Fifth Report and Order, 9 FCC Rcd 5581-5584
    (1995); 47 C.F.R. §§ 24.320(b) and 24.720(b).

[^319]: 13 C.F.R. § 121.201, NAICS code 517211.

[^320]: 13 C.F.R. § 121.201, NAICS code 517210.

[^321]: 13 C.F.R. § 121.201, NAICS codes 517211, 517210.

[^322]: U.S. Census Bureau, 2002 Economic Census, Subject Series:
    Information, "Establishment and Firm Size (Including Legal Form of
    Organization," Table 5, NAICS code 517211 (issued Nov. 2005).

[^323]: *Id.* The census data do not provide a more precise estimate of
    the number of firms that have employment of 1,500 or fewer
    employees; the largest category provided is for firms with "1000
    employees or more."

[^324]: U.S. Census Bureau, 2002 Economic Census, Subject Series:
    Information, "Establishment and Firm Size (Including Legal Form of
    Organization," Table 5, NAICS code 517212 (issued Nov. 2005).

[^325]: *Id.* The census data do not provide a more precise estimate of
    the number of firms that have employment of 1,500 or fewer
    employees; the largest category provided is for firms with "1000
    employees or more."

[^326]: Amendment of Part 90 of the Commission's Rules to Provide for
    the Use of the 220-222 MHz Band by the Private Land Mobile Radio
    Service, PR Docket No. 89-552, Third Report and Order and Fifth
    Notice of Proposed Rulemaking, 12 FCC Rcd 10943, 11068-70, ¶¶s.
    291-295, 62 FR 16004 (Apr. 3, 1997).

[^327]: *See* Letter to Amy Zoslov, Chief, Auctions and Industry
    Analysis Division, Wireless Telecommunications Bureau, FCC, from A.
    Alvarez, Administrator, SBA (Dec. 2, 1998).

[^328]: Revision of Part 22 and Part 90 of the Commission's Rules to
    Facilitate Future Development of Paging Systems, Memorandum Opinion
    and Order on Reconsideration and Third Report and Order, 14 FCC Rcd
    10030, ¶¶s. 98-107 (1999).

[^329]: *Id.* at 10085, ¶. 98.

[^330]: FCC Wireline Competition Bureau, Industry Analysis and
    Technology Division, "Trends in Telephone Service" at Table 5.3.,
    page 5-5 (Feb. 2007). This source uses data that are current as of
    October 20, 2005.

[^331]: *Id.*

[^332]: Public Notice, "Auction of Wireless Communications Services,
    Auction Notes and Filing Requirements for 128 WCS Licenses Scheduled
    for April 15, 1997," DA 97-386, Feb. 21, 1997.

[^333]: SBA Dec. 2, 1998 Letter.

[^334]: NAICS code 334220.

[^335]: NAICS code 11210.

[^336]: U.S. Census Bureau, 2002 NAICS Definitions, "334220 Radio and
    Television Broadcasting and Wireless Communications Equipment
    Manufacturing";
    http://www.census.gov/epcd/naics02/def/NDEF334.HTM#N3342.

[^337]: 13 C.F.R. § 121.201, NAICS code 334220.

[^338]: U.S. Census Bureau, American FactFinder, 2002 Economic Census,
    Industry Series, Industry Statistics by Employment Size, NAICS code
    334220 (released May 26, 2005); http://factfinder.census.gov. The
    number of "establishments" is a less helpful indicator of small
    business prevalence in this context than would be the number of
    "firms" or "companies," because the latter take into account the
    concept of common ownership or control. Any single physical location
    for an entity is an establishment, even though that location may be
    owned by a different establishment. Thus, the numbers given may
    reflect inflated numbers of businesses in this category, including
    the numbers of small businesses. In this category, the Census
    breaks-out data for firms or companies only to give the total number
    of such entities for 2002, which was 929.

[^339]: *Id.* An additional 18 establishments had employment of 1,000 or
    more.

[^340]: U.S. Census Bureau, 2002 NAICS Definitions, "515120 Television
    Broadcasting" (partial definition);
    <http://www.census.gov/epcd/naics02/def/NDEF515.HTM>.

[^341]: 13 C.F.R. § 121.201, NAICS code 515120.

[^342]: "Concerns are affiliates of each other when one concern controls
    or has the power to control the other or a third party or parties
    controls or has to power to control both." 13 C.F.R. § 21.103(a)(1).

[^343]: FCC News Release, "Broadcast Station Totals as of September 30,
    2005."

[^344]: *See* Broadcast Station Totals, *supra* IRFA, n. 11.

[^345]: "\[Business concerns\] are affiliates of each other when one
    concern controls or has the power to control the other or a third
    party or parties controls or has to power to control both." 13
    C.F.R. § 121.103(a)(1).

[^346]: 5 U.S.C. § 603(c)(1) -- (c)(4).

[^347]: *See infra*, n.53.

[^348]: *See infra* ¶ 12.

[^349]: *See infra* ¶ 33.