Election Whether to Participate in the Commercial Mobile Alert System

FCC-07-214A1

Election Whether to Participate in the Commercial Mobile Alert System

OMB: 3060-1113

⚠️ Notice: This form may be outdated. More recent filings and information on OMB 3060-1113 can be found here:

Document [pdf]

Download: pdf | pdf

Federal Communications Commission

FCC 07-214

Before the
Federal Communications Commission
Washington, D.C. 20554

In the Matter of
The Commercial Mobile Alert System

)
)
)
)
)

PS Docket No.07-287

NOTICE OF PROPOSED RULEMAKING
Adopted: December 14, 2007;

Released: December 14, 2007

Comment Date: [30 days from the date of publication in Federal Register]
Reply Comment Date: [45 days from the date of publication in Federal Register]
By the Commission:
I.

INTRODUCTION

1. With this Notice of Proposed Rulemaking (NPRM), we initiate a comprehensive rulemaking
to establish a Commercial Mobile Alert System (CMAS), under which Commercial Mobile Service
providers may elect to transmit emergency alerts to the public. This proceeding represents our next step
in compliance with the Warning Alert and Response Network (WARN) Act 1 requirement that the
Commission enable commercial mobile service alerting capability for providers that elect to transmit
emergency alerts. 2 In addition, with this rulemaking we continue to address our obligations under the
President’s “Public Alert and Warning System” Executive Order that the Commission “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.” 3
2. Section 602 of the WARN Act requires the Commission to adopt: (1) system critical
protocols and technical requirements for the CMAS; (2) a mechanism under which commercial mobile
service providers (“CMS providers”)licensees 4 may elect to participate in the CMAS and disclose to their
subscribers whether or not they will participate; (3) rules under which licensees and permittees of
noncommercial educational (NCE) broadcast stations or public broadcast stations install necessary
equipment and technologies on, or as part of, any broadcast television digital signal transmitter to enable
the distribution of geographically targeted alerts by CMS providers that have elected to participate in the
CMAS; and (4) technical testing requirements for CMS providers that elect to transmit emergency alerts
and for the devices and equipment used by such providers for transmitting such alerts. In this NPRM we
1

Security and Accountability For Every Port Act of 2006 (SAFE Port Act), Pub.L. 109-347, Title VI-Commercial
Mobile Service Alerts (WARN Act).

WARN Act, §602(a).

See Public Alert and Warning System, Exec. Order No. 13,407, 71 Fed. Reg. 36975 (2006) (Executive Order),
§3(b)(iii).
4

For purposes of Section 602 of the 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). WARN Act §
602(b)(1)(A).

Federal Communications Commission

FCC 07-214

seek comment on questions pertaining to all of these statutory requirements. 5 We also seek comment
about how the issues discussed in the NPRM relate to the Commission’s activities in connection with the
Emergency Alert System (EAS). 6
3. By starting this rulemaking 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 impending disasters and other emergencies irrespective of
what communications technologies they use. As we have learned from recent disasters such as the
Southern California fires, the Virginia Tech shootings, and 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 rulemaking represents our continued commitment to satisfy the mandate of
the Communications Act that the Commission promote the safety of life and property through the use of
wire and radio communication. 7
4. This NPRM is the latest example of our commitment to enhance the redundancy, reliability
and security of emergency alerts to the public by requiring that alerts be distributed over diverse
communications platforms. Most recently, we expanded the EAS from its legacy in 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. 8 As
we noted in our 2005 EAS Further Notice of Proposed Rulemaking, wireless services are becoming equal
to television and radio as an avenue to reach the American public quickly and efficiently. 9 As of June
2007, approximately 243 million Americans subscribed to wireless services. 10 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 rely on their
mobile telephony service to receive and retrieve critical, time-sensitive information. A comprehensive
mobile alerting system would have the ability to reach people on the go in a short timeframe, even where
they do not have access to broadcast radio or television or other sources of EAS. Providing critical alert
information in this respect will ultimately help avert danger and save lives.
II.

BACKGROUND

5. On October 13, 2006, the President signed the Security and Accountability For Every Port
(SAFE Port) Act into law. 11 Title VI of the SAFE Port Act, the WARN Act, establishes a process for
CMS providers to elect to transmit emergency alerts to their subscribers. The WARN Act requires that
5

As discussed in greater detail, infra, the WARN Act imposes different deadlines on the rulemakings required by
sections 602(a), (b), and (c). We intend to complete these rulemakings through one or more orders on or before the
relevant deadlines.
6

See, e.g., Review of the Emergency Alert System; Independent Spanish Broadcasters Association, the Office of
Communication of the United Church of Christ, Inc., and the Minority Media and Telecommunications Council,
Petition for Immediate Relief, EB Docket No. 04-296, Second Report and Order and Further Notice of Proposed
Rulemaking, 22 FCC Rcd 13275 (2007)( EAS Second Report and Order and Further Notice of Proposed
Rulemaking).
7

See 47 U.S.C. § 151.

See Review of the Emergency Alert System, EB Docket No. 04-296, First Report and Order and Further Notice of
Proposed Rulemaking, 20 FCC Rcd 18625 (2005) (EAS First Report and Order and Further Notice) at 18626.

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 viewed on December 12, 2007).
11

See note 2, supra.

Federal Communications Commission

FCC 07-214

we engage in a series of activities to accomplish that goal. These requirements are listed below, followed
by our activity to satisfy that requirement:

•

By December 12, 2006 (60 days of enactment), we were required to establish an
advisory committee to recommend system critical protocols and technical
recommendations for the CMAS, and arrange for the Committee to hold its first
meeting. 12 We formed the Commercial Mobile Service Alert Advisory Committee
(CMSAAC), which had its first meeting on this date. 13

•

By April 13, 2007 (180 days of enactment), we were required to determine what
constitutes “remote communities effectively unserved by commercial mobile service [
] for the purpose of enabling residents of those communities to receive emergency
alerts.” This required determination relates to a program 14 under which NOAA may
issue grants to provide for outdoor alerting technologies. We issued a Declaratory
Ruling addressing this issue on April 11, 2007. 15

•

By October 12, 2007 (one year of enactment), the CMSAAC was required to provide
system critical recommendations regarding technical requirements and protocols for
the CMAS to the Commission. 16 The CMSAAC submitted its report on this date. The
CMSAAC recommendations are attached at Appendix B. 17

•

Within 180 days of receipt of the CMSAAC’s recommendations, we must complete a
proceeding to adopt 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. 18

•

Within 90 days of our adoption of CMAS technical requirements, we must complete a
proceeding to require NCE and public broadcast station licensees and permittees to
install equipment to enable the distribution of geographically targeted alerts by CMS

WARN Act, sections 603(a), (d).

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 the National Oceanic & Atmospheric Administration (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, DA 06-2474 (2006).
14

See WARN Act, section 605.

In the Matter of Implementation of a Grant Program for Remote Community Alert Systems Pursuant to Section
605(a) of the Warning, Alert, and Response Network (WARN) Act, PS Docket No. 07-8, Declaratory Ruling, 22
FCC Rcd 7214 (2007).
16

WARN Act, section 603(c).

The CMSAAC held a total of 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.

WARN Act, section 602(a).

Federal Communications Commission

FCC 07-214

providers that have elected to transmit emergency alerts.

III.

•

Within 120 days of our adoption of CMAS technical requirements, we must complete
a proceeding that, among other things, establishes the process by which CMS
providers would elect to transmit emergency alerts to subscribers. 19

•

Within two years after completion of the technical rulemaking, we must examine
whether CMS providers electing to transmit emergency alerts should continue to
permit their subscribers the capability to block such alerts and must submit a report
with its recommendations to Congress. 20

DISCUSSION
A.

WARN Act Section 602(a) - Technical Requirements

6. Section 602(a) of the WARN Act requires that the Commission adopt technical standards,
protocols, procedures, and other technical requirements based on the recommendations of the CMSAAC
that will enable commercial mobile service alerting capability for CMS providers that voluntarily elect to
transmit emergency alerts. The CMSAAC has recently completed its report, 21 and we seek comment
generally on all the recommendations contained therein. Accordingly, we seek comment on the technical
standards, protocols, procedures and other requirements that should be adopted to facilitate the
transmission of emergency alerts by CMS providers. 22 We ask whether these recommendations, if
adopted, would satisfy the requirements of the WARN Act and our goal of ensuring a robust, reliable and
effective CMAS that could, in conjunction with other alerting systems and technologies, be used to
transmit emergency alerts to all Americans, including those with special needs and those who do not
speak English. We seek comment on whether the CMSAAC recommendations present an effective
mechanism for alert originators at all levels of government to initiate emergency alerts and whether these
recommendations could be implemented using a myriad of current and future technologies. Commenters
should review all of the recommendations and comment, where appropriate, on the manner in which each
of the recommendations contributes to an effective, unified system for the delivery of alerts over
commercial mobile systems as envisioned by the WARN Act. 23 We further seek comment on any
alternatives to the CMSAAC’s recommendations. Comments that suggest alternatives to the CMSAAC’s
recommendations should address with sufficient detail how their proposed alternative would promote an
effective CMAS as envisioned by the WARN Act.

Id., section 602(b)(1).

Id., section 602(b)(1)(E).

Under the CMSAAC’s proposed end-to-end CMAS, a Federal government entity, the “Alert Aggregator,” would
receive, aggregate and authenticate alerts originated by authorized alert initiators. Under this proposal, the Federal
government entity would also serve as an “Alert Gateway” which would formulate alerts based on CMPS profiles
and then send them to CMS provider “Gateways” across a secure interface. The CMS provider Gateway would send
the alerts to the participating CMS providers’ infrastructure which, in turn, would send them to a subscriber’s mobile
device. The CMSAC recommendations include proposed technical requirements for virtually every component of a
CMAS, including proposed government and CMS provider elements, alerting requirements geo-targeting
requirements, and proposed standards for security reliability and performance.
22

See CMSAAC recommendations at section 1.1.1.

Commenters may use as the basis of their comments not only the Recommendations, but also the record on which
the recommendations are based including the video records of the CMSAAC meetings and any materials submitted
to the CMSAAC as public comments. These materials are available on the CMSAAC web site at
http://www.fcc.gov/pshs/cmsaac/.

Federal Communications Commission

FCC 07-214

7. The CMSAAC’s recommendations are detailed and highly technical in many places. As
noted above, we have attached the CMSAAC’s recommendations at Appendix B to this NPRM.
Accordingly, rather than summarize each of the recommendations in this document, we provide
descriptions of the major issues addressed by the CMSAAC’s recommendations in order to facilitate a
focused approach for public comment.
1.

Available Transport Technologies

8. We seek comment on the availability of technologies now and in the future for the
transmission of alerts over the CMAS. For example, to what extent do point-to-point and point-tomultipoint technologies provide viable solutions for a national CMAS? In this regard, we note that, the
CMSAAC raised concerns regarding the viability of point-to-point solutions for a national alerting
system. 24 We seek comment on these concerns. Specifically, can current generation point-to-point
services such as short message service (SMS) be used to efficiently alert large populations of people
within a short time frame? What impact would wireless 3G networks have on the SMS model?
9. Can point-to-multipoint technologies such as cell broadcast provide a viable transport
solution for alerts transmitted over the CMAS? If current cell broadcasting does not provide a viable
solution, what further development would be necessary to use cell broadcasting for the CMAS? Are there
significant differences in how CDMA or GSM systems could employ cell broadcasting today and in the
future? Are current mobile devices capable of receiving cell broadcast alerts?
10. We also seek comment, particularly from the EAS community, on whether a broadcast
distribution model similar to that used to distribute EAS is consistent with the WARN Act and the
CMAS. Could radio data systems like the Radio Broadcast Data System (RBDS), which do not require
significant service provider infrastructure, nonetheless meet our goals for efficient delivery of alerts over
the CMAS? What about emerging wireless broadcast technologies such as MediaFLO and DVB-H? 25
Comments should include a discussion concerning the broad range of devices intended to utilize the
CMAS and potential impact on the subscriber service experience.
11. The CMAS as proposed by the CMSAAC likely will require a higher layer protocol that
carries meta-data (administrative information) with the alert message, and can send authentication and
authorization data to the alert’s originator. We seek comment on whether this higher layer protocol is
necessary for the CMAS. We also seek comment on how point-to-point, point-to-multi point and
broadcast models could carry this information and provide the recommended authentication information.
We further seek comment on any alternative methods for transmitting this data.
2.

Federal Government’s Role

12. What should be the Federal Government’s role, if any, in managing the CMAS? The
CMSAAC recommended that a Federal Government entity fulfill the roles of “Alert Aggregator” (i.e.,
receive, accumulate and authenticate alerts originated by authorized alert initiators using the Common
Alert Protocol (CAP)) 26 and the “Alert Gateway” (i.e., formulate an alert based on key fields in the CAP
alert sent by the alert initiator and transmit the alert to corresponding gateways operated by each CMS
provider). We seek comment on these recommendations. Is it necessary and desirable for a Federal
government entity to assume these roles? If so, what Federal government entity would be appropriate?
24

We note that the CMSAAC recommended that these technologies not be considered as part of the CMAS. See
CMSAAC recommendations at section 5.2.
25

See CMSAAC recommendations at section 5.2. MediaFLO and DVB-H are technologies developed to transmit
television signals and other data to portable devices such as cell phones and PDAs.

CAP is defined and discussed in detail in paragraph 14, infra.

Federal Communications Commission

FCC 07-214

Commenters suggesting that a Federal government entity other than the Commission should fulfill these
roles should also address how we could implement such a recommendation, taking into account our
statutory authority and jurisdiction. We also seek comment on whether a private sector entity could fulfill
these roles either independently or pursuant to delegated authority by a Federal government entity (e.g.,
under a “Memorandum of Understanding” (MoU) arrangement, similar to the one used by the Justice
Department regarding Amber Alerts).
13. The CMSAAC also recommended that all alerts, whether national or local, would be funneled
through this aggregator. Is a centralized system best positioned to accomplish the goals of the CMAS as
envisioned by the WARN Act? Would this run the risk of creating a single point of failure? Further, we
seek comment on the government alerting system capability to a) support the aggregation of alerts from
emergency agencies down to county and municipal levels, b) distribute alerts to a diverse range of
potential alerting systems, and c) interact and determine the status of such connected alerting systems.
What is the role of state emergency agencies in such a scheme? Should the aggregator concept be
expanded to include state and county emergency agencies, such as state and county emergency operations
centers (EOCs)? Could this be done in a manner that could track a state’s role in any EAS activation?
What equipment or security issues might be involved in expanding the scope of the system? What criteria
should be established for determining the appropriateness of connecting an agency? What responsibilities
should be attendant on connected agencies?
3.

Use of the Common Alerting Protocol (CAP)

14. We seek comment on the CMSAAC’s recommendation that the CMAS use CAP as the basic
alerting protocol from the alert initiator to the alert gateway. 27 We also seek comment about the use of
CAP as a general, system-wide CMAS interface. 28 Is use of CAP currently practicable in the context of
CMAS? If CAP use were mandated, how quickly could such use be introduced by all CMAS
participants? We note that we have specifically mandated use of CAP recently in our EAS Second Report
and Order, where we concluded that use of CAP would provide specific benefits to the evolving EAS. 29
As noted above, one of the key benefits of CAP is that it ensures that diverse alert systems and
technologies can participate within a common, transparent framework. Would CAP as utilized in the
context of CMAS promote similar transparency? To the extent that commenters believe that the use of
CAP as proposed would not be appropriate, they should discuss in detail any alternative protocols.
4.

Alert Formatting, Classes, and Content Issues

15. We seek comment on whether we should adopt a character limit for alerts transmitted over
the CMAS. We note that the CMSAAC recommended that, at least initially, the technical limit of any
CMAS alert should be 90 characters of text. 30 Commenters should provide detailed technical explanation
27

See CMSAAC recommendations at section 1.1.1.

CAP is an open, interoperable standard, whose standardized alert message format – based on the World Wide
Web Consortium’s (“W3C’s”) Extensible Markup Language (“XML”) – is a text-based format that facilitates data
sharing across different distribution systems. The agreed-upon XML format of CAP can be accepted by a wide
variety of devices or systems, and the format also permits links to voice, audio or data files, images, and multilingual
translations of the alert, and to links providing further information. The CAP standard specifies what fields an alert
message can contain and what information can be included in the particular fields. A CAP alert can provide various
fields, including message type, scope, incident, event information, event certainty, sender, geographic scope, and the
time when an alert becomes effective and expires. CAP also facilitates interoperability between devices, an attribute
essential to establishing a CMAS that can operate over multiple service platforms. See generally, EAS Second
Report and Order.
29

See EAS Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC Rcd at 13288 (noting
that CAP is mandated only in the event it is adopted by the Federal Emergency Management Agency (FEMA).)
30

See CMSAAC recommendations at section 1.1.1.

Federal Communications Commission

FCC 07-214

in support of their positions and explain the relationship between “payload” and “displayable message
size” as referenced in the CMSAAC’s recommendations? 31
16. We also seek comment on whether and to what extent emergency alerts should be classified.
We specifically seek comment on the CMSAAC’s recommendation that there be three classes of
Commercial Mobile Alerts: Presidential-level, Imminent threat to life and property; and Child Abduction
Emergency or “AMBER Alert” Service. 32 For example, the CMSAAC recommended that the term
“Imminent threat to life and property” be defined as “alerts where the CAP severity equals Extreme or
Severe, CAP urgency is Immediate or Expected, and CAP certainty is Observed or Likely.” Is this
proposed definition sufficient to set a proper threshold for the class of alerts that should be transmitted
using the CMAS? We solicit examples of events meeting these criteria. Further, we seek comment on
whether the choice of “imminent” represents a correct threshold? Does “imminent” apply to all types of
threats, such as weather for example? Also, we note that CMS providers already support the transmission
of Amber alerts to mobile devices using SMS technology. What is the added value of also including
Amber Alerts in CMAS? What are the potential negatives if “too many” alerts are generated? What
balance of alerts should be sought, and what factors should be considered in seeking such a balance?
17. We also seek comment on the content of CMAS alerts, including the CMSAAC’s
recommendation that all service providers support, at minimum, a capability for a text based common
alerting message format support across multiple service platform technologies. 33
18. The CMSAAC also recommended that the elements of a Commercial Mobile Alert Message
(CMAM) should be (1) event type or category, (2) area affected, (3) recommended action, (4) expiration
time with time zone, and (4) sending agency. 34 We seek comment on these choices. Are they consistent
with accepted industry practices for emergency alerts? Are they consistent with the evolving concept of
CAP-formatted messages? The CMSAAC anticipated that the elements of a CMA would evolve as
experience is gained by alert initiators. We seek comment on this assumption. How might CMAM
elements evolve over time?
19. The CMSAAC also recommended a method for the automatic generation of alert text by
extracting information from CAP fields, SAME codes and free-form text, but proposed that the CMAS
allow the generation of free text in Amber Alerts and Presidential alerts. 35 . We seek comment on this
recommendation. We also seek comment on whether Presidential and Amber alerts can be structured to
use automatic text.
20. We also seek comment on the CMSAAC’s recommended set of standardized alerting
messages. Should the alert message include telephone numbers, URLs or other response and contact
information in certain Commercial mobile alerts? 36 Is there public safety value to the inclusion of such
information in a Commercial mobile alert? What, if any, would be the impact on the network? In prior
emergencies, mobile traffic increased to the point of network congestion. What would be the impact on

See id. at section 1.1.5.

See id. at section 5.1.

See id. at section 5.3.1.

See id. at section 5.3.2.

We note there was considerable discussion of this issue during the October 3 CMSAAC meeting. See Transcript
of October 3, 2007 Meeting, at pp. 121-133, available at http://www.fcc.gov/pshs/cmsaac/cmsaac-meetings.html
(last viewed December 12, 2007).

Federal Communications Commission

FCC 07-214

network congestion if subscribers were directed to a specific number (such as a “311” number in New
York City) or URL?
5.

Geographically Targeted Commercial Mobile Alerts

21. We seek comment on what level of precision we should require for the geographical targeting
(geo-targeting) of CMAS alerts. In section 5.4 of its recommendations, the CMSAAC acknowledged
“that it is the goal of the CMAS for CMSPs to be able to deliver geo-targeted alerts to the area specified
by the Alert Initiator.” 37 However, the CMSAAC recommended that, due to current limited capabilities
on the part of CMS providers, “an alert that is specified by a geocode, circle or polygon . . . will be
transmitted to an area not larger than the CMSP’s approximation of coverage for the county or counties
with which that geocode, circle or polygon intersects.” 38 We seek comment on this recommendation,
including the assertion that technical limitations currently preclude dynamic geo-targeting at a level more
granular than the county. 39
22. The CMSAAC recognized that a “CMS provider may elect to target smaller areas” and
recommended “that certain urban areas with populations exceeding 1,000,000 inhabitants or with other
specialized alerting needs be identified for priority consideration regarding implementation of more
precise geo-targeting.” 40 The CMSAAC recommended that a process be initiated by the Alert Gateway
operator and the CMS providers to identify such priority locations by August, 2008, and recognized “the
desire to move forward with this process on a small number of areas with particularly urgent alerting
needs as soon as possible.” 41 We seek comment on these and the other recommendations raised in
section 5.4 of the CMSAAC’s recommendations.
6.

CMAS for Individuals with Disabilities and the Elderly

23. We seek comment on what, if any, technical or accessibility requirements we should adopt to
ensure that commercial mobile alerts can be received by people with disabilities and the elderly. 42 The
37

CMSAAC recommendations at section 5.4.

Id. at section 5.4.1.

See id. at section 5.4 (“The CMSAAC further recognizes that CMSPs currently have limited capability to deliver
geo-targeted alerts.”). See also Presentation of Brian Daly, Leader of CMSAAC’s Communications Technology
Group, CMSAAC Transcript of September 19, 2007 Meeting at pp 28 (“It’s really the issue with dynamically
matching to RF coverage areas because if you take a map and draw a polygon or a circle, it’s challenging to figure
out what cell sites are covering the area within that circle or polygon on a real-time basis, and that’s where the
challenge comes in. . . .The technology needs to be evaluated to see what can be done in order to get down to those
geographic areas.”).
40

CMSAAC recommendations at section 5.4.1.a. We note that during a conference call on the topic of geotargeting subsequent to the September 19, 2007 CMSAAC meeting, the City of New York’s representative
expressed concern about county-based geo-targeting, particularly as it relates to the City of New York’s need to
receive alerts at a more granular level.

CMSAAC recommendation at section 5.4.1.a.

See SAFE Port Act, 120 Stat. 1936-43, WARN Act § 603(a). Beyond the WARN Act, there are numerous
Federal statutes and policies directed toward achieving accessibility for persons with disabilities. See, e.g.,
Americans With Disabilities Act of 1990 (ADA), Pub. L. No. 101-336, 104 Stat. 327, § 401 (1990) (Title II of ADA
requires accessibility to state and local government programs and communications); The Rehabilitation Act of 1973,
Pub. L. No. 93-112, 87 Stat. 394, 29 U.S.C. § 794, as amended (section 504 of the Rehabilitation Act requires
accessibility of Federal government programs); 47 U.S.C. § 255 (Communications Act accessibility requirements
for telecommunications services and equipment where readily achievable); Exec. Order No. 13,347, 69 Fed. Reg.
44,573 (July 22, 2004) (establishing policies to ensure that the Federal Government appropriately supports safety
and security for individuals with disabilities in situations involving disasters, and that Federal Government agencies
consider the unique needs of employees with disabilities, and other individuals with disabilities served by such
(continued....)

Federal Communications Commission

FCC 07-214

CMSAAC submitted recommendations addressing the needs of users, including individuals with
disabilities and the elderly, and we seek comment on these recommendations. 43 Among the major
recommendations by the CMSAAC is a proposal that the CMAS support a common audio attention signal
and a common vibrating cadence to be used solely for CMAS alerts. We seek comment on this
recommendation. Does the CMAS need to require these attention signals for all users? 44 Further, the
CMSAAC recommended that the alert initiator use clear and simple language whenever possible, with
minimal use of abbreviations and that the mobile device be able to provide an easy way to allow the user
to recall the message for review. We seek comment on these recommendations and other issues that
parties wish to raise concerning users with special needs. The CMSAAC also recommended that legacy
mobile devices not be required to support CMAS, notwithstanding that much of the special needs services
will depend on features in the mobile device. We seek comment on this recommendation. Is there a way,
perhaps through software upgrades, for present mobile devices to support CMAS? Could, and if so
should, upgrades be performed over the air?
7.

Transmission of CMAS Alerts in Languages Other than English

24. We seek comment on the technical feasibility of providing commercial mobile alerts in
languages in addition to English. The CMSAAC suggested that there may be fundamental technical
challenges to implementing parallel alerts in languages in addition to English. We seek comment on this
view. We recognize the significant public safety interest in delivering alerts to speakers of languages
other than English and strongly affirmed this principle in our May 2007 EAS Second Report and Order. 45
CMSAAC also asserted that multilingual (and geo-targeted) alerting would raise latency (alert delay)
concerns. 46 How would requirements for multi-language alerts affect the generation and distribution of
messages on a local, state and national level?
B.

WARN Act Section 602(b) - CMAS Election Rulemaking

25. Section 602(b) concerns commercial mobile service licensees’ election to transmit or not
transmit emergency alerts to subscribers. It requires the Commission to establish procedures by which a
CMS provider will notify new and existing subscribers of its election and inform the Commission of its
election and the method of its transmittal of alerts, and to establish procedures for a CMS provider to
withdraw its election and afford existing subscribers to discontinue service upon notification of that
withdrawal.
1.

Notice at Point of Sale

26. Under Section 602(b)(1), “within 120 days after the date on which [the Commission] adopts
relevant technical standards and other technical requirements pursuant to subsection (a), the Commission
shall complete a proceeding to allow any licensee providing commercial mobile service to transmit
emergency alerts to subscribers to, or users of, the commercial mobile service provided by such licensee.”
(...continued from previous page)
agencies, State, local, and tribal governments, and private organizations, in emergency preparedness planning);
Exec. Order No. 13,407, 71 Fed. Reg. 36,975 (June 26, 2006) (directing the Secretary of Homeland Security to
include in the public alert and warning system the capability to alert and warn all Americans, including those with
disabilities and those without an understanding of the English language).
43

See, e.g., CMSAAC recommendations at sections 5.5.2.1, 5.5.2.3.

See Federal Emergency Management Agency (FEMA), Accommodating Individuals with Disabilities in the
Provision of Disaster Mass Care, Housing, and Human Services, Reference Guide, at
http://www.fema.gov/oer/reference/.
45

See EAS Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC Rcd 13275, 13306.

See CMSAAC recommendations at section 1.1.8.

Federal Communications Commission

FCC 07-214

The Commission shall “require any CMS licensee providing commercial mobile service that elects, in
whole or in part, under paragraph (2) [Election] not to transmit emergency alerts to provide clear and
conspicuous notice 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.” 47
27. CMSAAC recommended that CMS providers should have the discretion to determine how to
provide this notice. Thus, as an initial matter, we seek comment on this recommendation. Alternatively,
should we specify the methods by which a service provider should notify prospective and existing
subscribers that it has elected not to offer emergency alerts? The Commission has established procedures
in other proceedings concerning the provision of notice to subscribers and the display of information in a
service provider’s places of business. 48 For purposes of this proceeding, we also would define any point
of sale as any means - retail, telephone, or Internet-based - by which a service provider facilitates and
promotes its services for sale to the public. We include third party, separately branded resellers as
meeting the criteria for a point of sale. We seek comment on this choice. 49 Are there others that should
be included?
28. In these commercial environments, what constitutes clear and conspicuous notice at the point
of sale? Does a general notice in the form of a statement attesting to the election not to provide
emergency alerts satisfy the statutory requirement? Does the language of the statute require the posting of
a general notice in clear view of subscribers in the service provider’s stores, kiosks, third party reseller
locations, web site (proprietary or third party), and any other venue through which the service provider’s
devices and services are marketed or sold? What form would that general notice take; for example,
should service providers include a placard of a particular size at the point of sale? Is notification in the
service provider’s service subscription terms and conditions sufficient notice to subscribers? Does the
clear and conspicuous standard require that each device sold by the service provider include a notice that
emergency alerts are not included as a feature of the device or the service provider’s service? Does a
service provider meet the condition of clear and conspicuous notification if it requires subscribers to read
and indicate an understanding that the service provider does not offer emergency alerts? The CMSAAC
has drafted recommended text by which CMS providers may indicate that they will not be electing to
participate in the CMAS. 50 We seek comment on this text. Does it satisfy the statute?
29. The CMSAAC suggested that, because the WARN Act does not require any disclosure for a
CMS provider that participates in the CMAS, no disclosure is required. We seek comment on this
assertion. If a CMS provider only offers CMAS within part of its territory or only on certain mobile
devices, where and how should the disclosure obligations apply?
2.

Notifications to Existing Subscribers

30. With respect to existing subscribers, under section 602(b)(1)(C), the Commission shall
“require any licensee providing commercial mobile service that elects under paragraph (2) not to transmit
47

WARN Act, section 602(b)(1)(B).

See, e.g., 47 C.F.R. § 63.71 (requiring any domestic service provider that seeks to discontinue, reduce or impair
service to notify all affected subscribers of the planned discontinuance, reduction, or impairment of service,
including a notice in writing to each affected subscriber with FCC mandated text); 47 C.F.R. § 63.90 (requiring a
service provider discontinuing service to post a public notice of 20 inches by 24 inches in a conspicuous place and
containing all pertinent information related to the discontinuance).

We note that the Commission has extended certain obligations to resellers. For example, the Commission requires
resellers of commercial mobile services to ensure that all mobile devices or other devices offered to their subscribers
for voice communications are capable of transmitting enhanced 911 information to the appropriate PSAP. See 47
C.F.R. § 20.18(m).
50

See CMSAAC recommendations at section 3.4.

Federal Communications Commission

FCC 07-214

emergency alerts to notify its existing subscribers of its election.” 51 Should CMS providers be granted
the discretion to determine how to provide notice of non-election? If not, we seek comment on how such
notification should be made, including the methods and duration of a service provider’s notification to
existing subscribers of its election. Commercial mobile service providers regularly communicate service
and equipment offers and upgrades to existing subscribers through direct mailings and through
notification on paper bills. Do existing marketing and billing practices allow service providers to meet
the requirement to notify existing subscribers of the service provider’s election? Are these types of
existing communication methods sufficient to reach the service provider’s entire existing subscriber base?
Commenters should take into account the fact that some service providers are offering their subscribers
electronic billing and do not send a paper bill, and some service providers have opt-out programs
allowing their subscribers to decline receiving any direct mailings from the service provider. Should
service providers be required to notify existing subscribers by sending them a separate notice of a change
in the terms and conditions of their service? 52 How should service providers notify pre-paid customers?
Should service providers demonstrate to the Commission that they have met this requirement and, if so,
how should they do so? 53 Should service providers be required to maintain a record of subscribers who
have acknowledged receipt of the service provider’s notification?
3.

Related Filings and Other Requirements

31. Sections 602(b)(2)(A), (B), (D) and (E) establish certain requirements for service providers
electing to provide or not to provide emergency alerts to subscribers. As specified in the timelines of the
WARN Act, the election process must be complete in September 2008. In several instances, the statute
requires service providers to submit notifications to the Commission indicating its election, non-election,
or its withdrawal from providing emergency alerts. Section 602(b)(2)(A) requires that, “within 30 days
after the Commission issues its order under [section 602(b)], each licensee providing commercial mobile
service shall file an election with the Commission with respect to whether or not it intends to transmit
emergency alerts.” 54 Similarly, under section 602(b)(2)(B), a service provider that elects to transmit
emergency alerts must “notify the Commission of its election” and “agree to transmit such alerts in a
manner consistent with the technical standards, protocols, procedures, and other technical requirements
implemented by the Commission.” 55 Further, section 602(b)(2)(D) requires the Commission to establish
procedures relating to withdrawal of an election and the filing of late election notices with the
Commission. 56 Under section 602(b)(2)(D)(i), “the Commission shall establish a procedure for a
commercial mobile service licensee that has elected to transmit emergency alerts to withdraw its election
without regulatory penalty or forfeiture upon advance written notification of the withdrawal to its affected
subscribers.” 57 Finally, section 602(b)(2)(D)(ii) requires “the Commission to establish a procedure for a
commercial mobile service licensee to elect to transmit emergency alerts at a date later than provided in

WARN Act, section 602(b)(1)(C).

For example, the Commission requires interconnected VoIP service providers to advise every subscriber, both
new and existing, prominently and in plain language, of the circumstances under which E911 service may not be
available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911
service. See 47 C.F.R. § 9.5(e)(1).

See, e.g., 47 C.F.R. § 9.5(e)(2) (requiring interconnected VoIP service providers to obtain and keep a record of
affirmative acknowledgment by every subscriber, both new and existing, of having received and understood the
advisory on the limitations and availability of E911 service over VoIP platforms).

WARN Act, section 602(b)(2)(A).

Id, section 602(b)(2)(B)(i-ii).

Id., section 602(b)(2)(D).

Id., section 602(b)(2)(D)(i).

Federal Communications Commission

FCC 07-214

subparagraph (A).” 58 The CMSAAC proposed a timeline for election based on its interpretation of the
WARN Act. 59 We seek comment on this interpretation and timeline. Commenters with a different
interpretation should provide detailed alternatives.
32. With respect to all these filing requirements, we request comment on the most efficient
method for accepting, monitoring, and maintaining service provider election and withdrawal information.
We anticipate that this information will be of interest to the public and will serve to aid consumers in their
decision regarding which service provider can best meet their expectations for delivering emergency
alerts. Should the Commission require electronic filing of the submission? With respect to the initial
filing by the service provider of its intention to provide or not to provide emergency alerts, what should
the CMS provider provide in its report to the Commission if it indicates its intention to provide
emergency alerts? For example, we seek comment on the CMSAAC’s recommendations that, at a
minimum, a CMS provider explicitly commits to support the development and deployment of technology
for the following: the “C” reference point, the CMS provider Gateway, the CMS provider infrastructure,
and the mobile device with CMAS functionality. The CMSAAC also suggests that the required
technology may not be in place for some time. Accordingly, should electing CMS providers be able to
specify when they will be able to offer mobile alerting?
33. With respect to notification that the service provider elects to provide emergency alerts, we
seek comment on the manner by which service providers shall notify the Commission and attest to their
adoption of the Commission’s standards, protocols, procedures and other technical requirements. Should
the Commission require electronic filing of the submission? What should the CMS provider submit in its
report to the Commission if it indicates its intention to provide emergency alerts? 60
34. The statute allows service providers to withdraw from their election to provide emergency
alerts, upon notification to the Commission and to subscribers. We seek comment on the proper
mechanism for service providers to file this withdrawal with the Commission. We contemplate two
scenarios: first, the service provider has elected to provide emergency alerts, but does not build the
infrastructure, or second, the service provider elects to provide emergency alerts, does so to all or some
portion of its coverage area, but then chooses to no longer provide alerts and elects to discontinue the
service. With respect to the second scenario, how much advance service provider notification to
subscribers should the Commission require prior to the service provider’s withdrawal of the service?
What methods should service providers use to notify all existing subscribers at the service provider’s
various points of sale? Should the Commission impose the same set of requirements considered under
section 602(b)(1)(C) regarding notification to existing subscribers and potential subscribers that a service
provider has elected not to provide emergency alerts? Were the Commission to allow some cost recovery
mechanism, 61 what changes in that process should be required when a service provider ceases to provide
emergency alerts? Should service providers be required to demonstrate or certify that they are no longer
passing through costs to implement emergency alerts to subscribers? 62
35. Section 602(b)(2)(D)(iii) requires the Commission to establish a procedure “under which a
subscriber may terminate a subscription to service provided by a commercial mobile service licensee that
withdraws its election without penalty or early termination fee.” 63 We seek comment on the procedures
58

Id., section 602(b)(2)(D)(ii).

See CMSAAC recommendations at section 12.2.

See, e.g., 47 C.F.R. § 9.5(e)(4) (requiring all interconnected VoIP providers to submit a letter to the Commission
detailing their compliance with E911 regulations).

See infra, ¶ 38.

See infra, ¶ 39.

WARN Act, section 602(b)(2)(D)(iii).

Federal Communications Commission

FCC 07-214

necessary to allow a subscriber to terminate service upon a service provider’s withdrawal of its election to
provide emergency alerts. In what manner should subscribers and potential subscribers be informed of
their right to discontinue service? Is notification in the terms and conditions of service sufficient to
apprise subscribers of their right to discontinue service without penalty or termination fee? Should the
Commission prescribe a specific procedure for subscribers or should service providers submit to the
Commission a description of their procedure for informing subscribers of their right to terminate service?
What should such procedures be?
36. Section 602(b)(2)(E) states that “any commercial mobile service licensee electing to transmit
emergency alerts may offer subscribers the capability of preventing the subscriber’s device from
receiving such alerts, or classes of such alerts, other than an alert issued by the President.” 64 The
CMSAAC recommended that the CMS providers should offer their subscribers a simple opt-out
process. 65 With the exception of presidential messages, which are always transmitted, the CMSAAC
recommended that the process should allow the choice to opt out of “all messages,” “all severe
messages,” and AMBER Alerts. 66 The CMSAAC suggested that, because of differences in the way CMS
providers and device manufacturers provision their menus and user interfaces, CMS providers and device
manufacturers should have flexibility on how to present the opt-out choices to subscribers. We seek
comment on the recommendations of the CMSAAC with respect to three choices of message types that a
subscriber should be allowed to choose to opt out of receiving. We also seek comment on the CMSAAC
recommendation that CMS providers and device manufacturers should have flexibility or whether the
Commission should establish baseline criteria for informing subscribers of this capability and if any
uniform standards for conveying that information to subscribers is required. We understand that current
and future devices have different user interfaces and menu structures for enabling and disabling device
features. To what extent is a uniform methodology for disabling this feature necessary? Are there more
classes of alerts that should be considered?
37. Section 602(b)(2)(E) also provides that the Commission shall, within two years of the
adoption of the technical requirements, “examine the issue of whether a [CMS provider] should continue
to be permitted to offer its subscribers an opt-out capability.” 67 We seek comment on the appropriate
mechanism for doing so. Further, we seek comment on whether the Commission can expand the scope of
this inquiry to other questions concerning the development of the CMAS. We note that the CMSAAC
recommended this result because the CMAS is a new and untested system and will need periodic review
as it is deployed. 68 We seek comment on this recommendation.
38. Section 602(b)(2)(C) states “[a] commercial mobile service licensee that elects to transmit
emergency alerts may not impose a separate or additional charge for such transmission or capability.” 69
64

Id., section 602(b)(2)(E).

See CMSAAC Recommendations at section 5.5.3.

Id. Under the CMSAAC’s recommendation, when the subscriber chooses to opt out of “all messages,” only
“presidential” messages will be received. Id. at p 57, n.13. When the subscriber chooses to opt out of “all severe
messages,” only “extreme messages, AMBER Alerts and presidential messages will still be received.” Id. at p. 57,
n.14. “Extreme” messages correspond to events of near-catastrophic proportions. See Transcript of July 18, 2007
Meeting, at pp. 37-38, available at http://www.fcc.gov/pshs/cmsaac/cmsaac-meetings.html (last viewed December
12, 2007). In developing the recommendation, the Committee believed that it was important that subscribers who
opt out of “severe” alerts should still be able to receive these “extreme” alerts. See id. at p. 38. Finally, when the
subscriber chooses to opt out of AMBER alerts, all alerts aside from AMBER alerts will still be received. Id. at p.
57, n.15.

WARN Act, section 602(b)(2)(E).

See CMSAAC recommendations at section 5.

WARN Act, section 602(b)(2)(C).

Federal Communications Commission

FCC 07-214

Does this provision completely preclude a participating service provider’s ability to recover costs
associated with the provision of alerts? 70 What about CMAS-related services and technologies that are
not used to deliver CMAS? Should the section’s reference to “transmission or capability” be read
narrowly? For example, much of the alert technology will reside in the subscriber’s mobile device. Can
the CMS providers recover CMAS-related developmental costs from the subscriber through mobile
device charges based on a determination that mobile devices lie outside the “transmission or capability”
language of the section?
C.

WARN Act Section 602(c) - Digital Television Transmission Towers
Retransmission Capability Rulemaking

39. Section 602(c) of the WARN Act requires that within 90 days of adoption of the technical
requirements, we must complete a proceeding to require NCE and public broadcast station licensees and
permittees to install equipment and technologies on, or as part of, any broadcast television digital signal
transmitter to enable the distribution of geographically targeted alerts by CMS providers that have elected
to transmit emergency alerts. We seek comment on this requirement. Specifically, we seek comment on
whether the system described in this section is identical to the “Datacasting” system 71 that the Association
of Public Television Stations (APTS) and FEMA are deploying as the backbone of the Digital Emergency
Alert System (DEAS)? If so, would it be consistent with the WARN Act simply to implement the DEAS
in a manner that complies with section 602(c) of the WARN Act?
40. How will this DTV-based system interface with the CMAS? How will this requirement
regarding the geo-targeting of CMAMs fits into centrally administered CMAS as envisioned by the
CMSAAC. How would the DTV-based system implement the message formats defined by the “C”
interface? We also seek comment on the scope of this section. Although the caption of section 602(c)
refers to digital television transmissions, it mandates that the Commission impose any equipment
requirements to licensees and permittees of NCE and public broadcast stations as those terms are defined
under Section 397(6) of the Communications Act. That provision references both radio and television
broadcast stations. We seek comment on this definition as it relates to section 602(c) of the WARN Act.
Is it a fair reading of the language to conclude that this section applies only to licensees and permittees of
NCE and public broadcast television stations?
D.

WARN Act Section 602(f) - Testing

41. Section 602(f) of the WARN Act provides that the Commission shall “require by regulation
technical testing for commercial mobile service providers that elect to transmit emergency alerts and for
the devices and equipment used by such providers for transmitting such alerts.” We seek comment on
what type of testing regime the Commission should require. We note that the CMSAAC proposed that in
order to assure the reliability and performance of this new system, certain procedures for logging CMAS
alerts at the Alert Gateway and for testing the system at the Alert Gateway and on and end-to-end basis
should be implemented. 72 We seek comment on these proposed procedures. Do they satisfy the
70

We note that during the CMSAAC’s discussion of this issue, some members stated that it was anticipated that
mobile devices may incur additional development and costs which could be passed on to the subscriber. See
CMSAAC, Transcript of October 3, 2007 Meeting, at pp. 33- 62, available at
http://www.fcc.gov/pshs/cmsaac/cmsaac-meetings.html (last viewed December 12, 2007).
71

Datacasting is a one-way broadcast service where data is encoded and transmitted over-the-air within a public
television station's digital signal. The transmission is then decoded by an inexpensive receiver. Through
datacasting, digital public television stations can wirelessly distribute streamed video and data files to computers and
computer networks – with a capacity equal to thirteen T-1 data lines. Definition of Datacasting, The Association of
Public Television Stations (APTS), http://www.apts.org/PTVissues/digitalTV/datacasting.cfm.
72

See CMSAAC recommendations at section 9.5.

Federal Communications Commission

FCC 07-214

requirements of section 602(f) of the WARN Act? We particularly seek comment on whether there
should be some form of testing of the CMAS that sends test messages to the mobile device and the
subscriber. 73 Do the EAS testing rules offer a model for such tests? In those rules, internal systems test
are combined with tests that are heard (or in some cases seen) by the public. Should some similar form of
test that alerts the public be required in the CMAS? Should the testing process be invisible to the
subscriber or should all subscribers participate in certain tests? If testing involves subscribers, how
should subscribers be made aware of such tests?
E.

Overall Relationship of CMAS to EAS and Development of a National Alert
System by FEMA

42. As noted earlier, the Commission originally intended to consider in its rulemaking in EB
Docket No. 04-296 whether wireless mobile service providers should be included in the EAS. 74
Notwithstanding various operational differences between the EAS and those requirements mandated by
the WARN Act (chiefly, the voluntary participation model of the latter), both alert systems will provide
important emergency information to American citizens. As such, both systems would seem to qualify for
inclusion in the “national alert system,” to be developed and coordinated by FEMA, as envisaged by
President Bush’s June 2006 Executive Order. 75 We seek comment about how the CMSAAC’s proposals
for a CMAS relate to the directives contained in that Executive Order. We also seek comment about the
overall compatibility of the CMAS with the EAS (i.e., in addition to the specific questions that have been
raised earlier in this NPRM). Should we mandate such compatibility? What steps would we need to take
to ensure such compatibility? As related above, the CMSAAC has proposed use of CAP1.1 as the
standard CMAS alert interface, and the Commission has mandated that CAP1.1 shall also be the standard
interface for the evolving EAS (if it is adopted by FEMA). Would adoption and incorporation of CAP1.1
per the CMAS in and of itself ensure that it’s compatible with a CAP-formatted EAS alert delivery
system? If not, what modifications to the CMSAAC’s proposals would be necessary to ensure such
compatibility with the future National Alert System required under EO 13407? Finally, we also seek
comment on what additional statutory authority, independent of the WARN Act, we have to implement a
mobile alerting system.
IV.

PROCEDURAL MATTERS

43. Comments and Reply Comments. Pursuant to sections 1.415 and 1.419 of the Commission’s
rules, 47 C.F.R. §§ 1.415, 1.419, interested parties may file comments and reply comments on or before
the dates indicated on the first page of this document. All filings should refer to PSHSB Docket No. 07287. Comments may be filed using: (1) the Commission’s Electronic Comment Filing System (ECFS),
(2) the Federal Government’s eRulemaking Portal, or (3) by filing paper copies. See Electronic Filing of
Documents in Rulemaking Proceedings, 13 FCC Rcd 11322, 11326 (1998). For additional information
on this proceeding, please contact Jeffrey Goldthorp ((202) 418-1096) or Tom Beers((202) 418-0952).
44. Electronic Filers: Comments may be filed electronically using the Internet by accessing the
ECFS: http://www.fcc.gov/cgb/ecfs/ or the Federal eRulemaking Portal: http://www.regulations.gov.
Filers should follow the instructions provided on the website for submitting comments.

We note that there was discussion of this issue during the October 3 CMSAAC meeting. See Transcript of
October 3, 2007 Meeting, at pp. 155-159, available at http://www.fcc.gov/pshs/cmsaac/cmsaac-meetings.html (last
viewed December 12, 2007).
74

See EAS Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC Rcd 13275, 13298-99.

Public Alert and Warning System, Exec. Order No. 13407, 71 Fed. Reg. 36975 (June 26, 2006).

Federal Communications Commission

FCC 07-214

45. For ECFS filers, if multiple docket or rulemaking numbers appear in the caption of this
proceeding, filers must transmit one electronic copy of the comments for each docket or rulemaking
number referenced in the caption. In completing the transmittal screen, filers should include their full
name, U.S. Postal Service mailing address, and the applicable docket or rulemaking number. Parties may
also submit an electronic comment by Internet e-mail. To get filing instructions, filers should send an email to [email protected], and include the following words in the body of the message, “get form.” A sample
form and directions will be sent in response.
46. Paper Filers: Parties who choose to file by paper must file an original and four copies of each
filing. If more than one docket or rulemaking number appears in the caption of this proceeding, filers
must submit two additional copies for each additional docket or rulemaking number.
47. Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by
first-class or overnight U.S. Postal Service mail (although we continue to experience delays in receiving
U.S. Postal Service mail). All filings must be addressed to the Commission’s Secretary, Office of the
Secretary, Federal Communications Commission.
48. The Commission’s contractor will receive hand-delivered or messenger-delivered paper
filings for the Commission’s Secretary at 236 Massachusetts Avenue, NE., Suite 110, Washington, DC
20002. The filing hours at this location are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held
together with rubber bands or fasteners. Any envelopes must be disposed of before entering the building.
49. Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail)
must be sent to 9300 East Hampton Drive, Capitol Heights, MD 20743.
50. U.S. Postal Service first-class, Express, and Priority mail should be addressed to 445 12th
Street, SW, Washington DC 20554.
51. Comments and reply comments must include a short and concise summary of the substantive
discussion and questions raised in the NPRM. We further direct all interested parties to include the name
of the filing party and the date of the filing on each page of their comments and reply comments. We
strongly encourage that parties track the organization set forth in this NPRM in order to facilitate our
internal review process. Comments and reply comments must otherwise comply with section 1.48 and all
other applicable sections of the Commission’s rules. 76
52. People with Disabilities: To request materials in accessible formats for people with
disabilities (Braille, large print, electronic files, audio format), send an e-mail to [email protected] or call
the Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (tty).
53. Ex Parte Rules. These matters shall be treated as a “permit-but-disclose” proceeding in
accordance with the Commission's ex parte rules. 77 Persons making oral ex parte presentations are
reminded that memoranda summarizing the presentations must contain summaries of the substance of the
presentations and not merely a listing of the subjects discussed. More than a one or two sentence
description of the views and arguments presented is generally required. 78 Other requirements pertaining
to oral and written presentations are set forth in section 1.1206(b) of the Commission's rules. 79

See 47 C.F.R. § 1.48.

47 C.F.R. §§ 1.1200-1.1216.

47 C.F.R. § 1.1206(b)(2).

47 C.F.R. § 1.1206(b).

Federal Communications Commission

FCC 07-214

54. Initial Regulatory Flexibility Analysis. As required by the Regulatory Flexibility Act of
1980, as amended, see 5 U.S.C. § 603, the Commission has prepared an Initial Regulatory Flexibility
Analysis (“IRFA”) for this NPRM, of the possible significant economic impact on a substantial number
of small entities by the policies and rules proposed in this NPRM. The IRFA is in Appendix A. Written
public comments are requested on this IRFA. Comments must be identified as responses to the IRFA and
must be filed by the deadlines for comments on the NPRM. The Commission will send a copy of the
NPRM, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration. 80
In addition, the NPRM and IRFA (or summaries thereof) will be published in the Federal Register. 81
55. Initial Paperwork Reduction Act of 1995 Analysis. This document may contain proposed
new or modified information collection requirements. The Commission, as part of its continuing effort to
reduce paperwork burdens, invites the general public and the Office of Management and Budget (OMB)
to comment on the information collection requirements contained in this document, as required by the
Paperwork Reduction Act of 1995, Public Law 104-13. In addition, pursuant to the Small Business
Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment
on how we might “further reduce the information collection burden for small business concerns with
fewer than 25 employees.
V.

ORDERING CLAUSE

56. 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 Notice of Proposed
Rulemaking IS hereby ADOPTED.
57. IT IS FURTHER ORDERED that the Commission’s Consumer and Government Affairs
Bureau, Reference Information Center, SHALL SEND a copy of this Notice of Proposed Rulemaking,
including the Initial Regulatory Flexibility Analysis, to the Chief Council for Advocacy of the Small
Business Administration.
58. IT IS FURTHER ORDERED that the Commission’s Public Safety and Homeland Security
Bureau, SHALL SEND a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory
Flexibility Analysis, to the National Institute for Standards and Technology (NIST).

FEDERAL COMMUNICATIONS COMMISSION

Marlene H. Dortch
Secretary

See 5 U.S.C. § 603(a).

Id.

Federal Communications Commission

FCC 07-214

APPENDIX A
Initial Regulatory Flexibility Analysis
1. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), 1 the Commission
has prepared this present Initial Regulatory Flexibility Analysis (IRFA) of the possible significant
economic impact on a substantial number of small entities by the policies and rules proposed in this
Notice of Proposed Rulemaking (NPRM). Written public comments are requested on this IRFA.
Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments
on the NPRM provided in Section IV of the item. The Commission will send a copy of the NPRM,
including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). 2
In addition, the NPRM and IRFA (or summaries thereof) will be published in the Federal Register. 3
A.

Need for, and Objectives of, the Proposed Rules

2. With the NPRM, the Federal Communications Commission (Commission), as required by the
Warning Alert and Response Network (WARN) Act, 4 initiates a comprehensive rulemaking to establish a
Commercial Mobile Alert System (CMAS), under which Commercial Mobile Service providers
(alternatively, “CMS providers”) may voluntarily elect to transmit emergency alerts to the public. This
proceeding represents our next step in compliance with the Warning Alert and Response Network
(WARN) Act, that the Commission enable commercial mobile service alerting capability for CMS
providers that elect to transmit emergency alerts.
3. Section 602 of the WARN Act requires the Commission to adopt: (1) system critical
protocols and technical requirements for the CMAS; (2) a mechanism under which CMS providers 5 may
elect to participate in the CMAS and disclose to their subscribers whether or not they would participate;
(3) rules under which licensees and permittees of noncommercial educational (NCE) broadcast stations or
public broadcast stations install necessary equipment and technologies on, or as part of, any broadcast
television digital signal transmitter to enable the distribution of geographically targeted alerts by CMS
providers that have elected to participate in the CMAS; and (4) technical testing requirements for CMS
providers that elect to transmit emergency alerts and for the devices and equipment used by such
providers for transmitting such alerts. In this NPRM we seek comment on questions pertaining to all of
these statutory requirements. 6 We also seek comment about how the issues discussed in the NPRM relate
to the Commission’s activities in connection with the Emergency Alert System (EAS). 7

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

See 5 U.S.C. § 603(a).

Id.

See NPRM, note 1, supra.

See NPRM, note 4, supra, for definition of “commercial mobile service” under the WARN Act.

As discussed in the NPRM, the WARN Act imposes different deadlines on the rulemakings required by sections
602(a), (b), and (c). We intend to complete these rulemakings through one or more orders on or before the relevant
deadlines.

See NPRM, note 6, supra.

Federal Communications Commission

FCC 07-214

Legal Basis

4. Authority for the actions proposed in the NPRM may be found in 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.
C.

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

5. The RFA directs agencies to provide a description of, and, where feasible, an estimate of, the
number of small entities that may be affected by the rules adopted herein. 8 The RFA generally defines
the term “small entity” as having the same meaning as the terms “small business,” “small organization,”
and “small governmental jurisdiction.” 9 In addition, the term “small business” has the same meaning as
the term “small business concern” under the Small Business Act. 10 A “small business concern” is one
which: (1) is independently owned and operated; (2) is not dominant in its field of operation; and (3)
satisfies any additional criteria established by the Small Business Administration (SBA). 11
6. Small Businesses. Nationwide, there are a total of approximately 22.4 million small
businesses, according to SBA data.
7. Small Organizations. Nationwide, there are approximately 1.6 million small organizations.
8. Governmental Entities. The term “small governmental jurisdiction” is defined as
“governments of cities, towns, townships, villages, school districts, or special districts, with a population
of less than fifty thousand.” As of 2002, there were approximately 87,525 governmental jurisdictions in
the United States. This number includes 38,967 county governments, municipalities, and townships, of
which 37,373 (approximately 95.9%) have populations of fewer than 50,000, and of which 1,594 have
populations of 50,000 or more. Thus, we estimate the number of small governmental jurisdictions overall
to be 85,931 or fewer.
9. Wireless Telecommunications Carriers (except Satellite). Since 2007, the SBA has
recognized wireless firms within this new, broad, economic census category. 12 Prior to that time, the
SBA had developed a small business size standard for wireless firms within the now-superseded census
categories of “Paging” and “Cellular and Other Wireless Telecommunications.” 13 Under the present and
prior categories, the SBA has deemed a wireless 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

5 U.S.C. § 603(b).

5 U.S.C. § 601(6).

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

15 U.S.C. § 632.

13 C.F.R. § 121.201, NAICS code 517210.

13 C.F.R. § 121.201, NAICS codes 517211, 517212.

Federal Communications Commission

FCC 07-214

show that there were 807 firms that operated for the entire year. 14 Of this total, 804 firms had
employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more. 15
For the second category of Cellular and Other Wireless Telecommunications, data for 2002 show that
there were 1,397 firms that operated for the entire year. 16 Of this total, 1,378 firms had employment of
999 or fewer employees, and 19 firms had employment of 1,000 employees or more. 17 Thus, using the
prior categories and the available data, we estimate that the majority of wireless firms can be considered
small.
10. Cellular Service. As noted, the SBA has developed a small business size standard for small
businesses in the category “Wireless Telecommunications Carriers (except satellite).” 18 Under that SBA
category, a business is small if it has 1,500 or fewer employees. 19 Since 2007, the SBA has recognized
wireless firms within this new, broad, economic census category. 20 Prior to that time, the SBA had
developed a small business size standard for wireless firms within the now-superseded census categories
of “Paging” and “Cellular and Other Wireless Telecommunications.” 21 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.
11. For the first category of Paging, data for 2002 show that there were 807 firms that operated
for the entire year. 22 Of this total, 804 firms had employment of 999 or fewer employees, and three firms
had employment of 1,000 employees or more. 23 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. 24
Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of
1,000 employees or more. 25 Thus, using the prior categories and the available data, we estimate that the
majority of wireless firms can be considered small.
12. Auctions. In addition, 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
14

U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size
(Including Legal Form of Organization,” Table 5, NAICS code 517211 (issued Nov. 2005).
15

Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500
or fewer employees; the largest category provided is for firms with “1000 employees or more.”

U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, “Establishment and Firm Size
(Including Legal Form of Organization,” Table 5, NAICS code 517212 (issued Nov. 2005).
17

13 C.F.R. § 121.201, North American Industry Classification System (NAICS) code 517210.

Id.

13 C.F.R. § 121.201, NAICS code 517210.

13 C.F.R. § 121.201, NAICS codes 517211, 517212.

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).
23

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).
25

Federal Communications Commission

FCC 07-214

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.
13. 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. 26 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. 27 These small business size standards, in the
context of broadband PCS auctions, have been approved by the SBA. 28 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. 29 On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block licenses; there were 113
small business winning bidders. 30 On January 26, 2001, the Commission completed the auction of 422 C
and F PCS licenses in Auction 35. 31 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.
14. 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. 32 Through these auctions, the
Commission awarded a total of forty-one licenses, 11 of which were obtained by four small businesses. 33
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. 34 A “small
26

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

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.

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.

FCC News, “Broadband PCS, D, E and F Block Auction Closes,” No. 71744 (rel. January 14, 1997).

See “C, D, E, and F Block Broadband PCS Auction Closes,” Public Notice, 14 FCC Rcd 6688 (WTB 1999).

See “C and F Block Broadband PCS Auction Closes; Winning Bidders Announced,” Public Notice, 16 FCC Rcd
2339 (2001).

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).
33

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 9427 (rel. Nov. 9, 1994).

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

Federal Communications Commission

FCC 07-214

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. 35 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. 36 The SBA has approved these small business size standards. 37 A third
auction commenced on October 3, 2001 and closed on October 16, 2001. Here, five bidders won 317
(MTA and nationwide) licenses. 38 Three of these claimed status as a small or very small entity and won
311 licenses.
15. Wireless Communications Services. This service can be used for fixed, mobile,
radiolocation, and digital audio broadcasting satellite uses in the 2305-2320 MHz and 2345-2360 MHz
bands. The Commission defined “small business” for the wireless communications services (WCS)
auction as an entity with average gross revenues of $40 million for each of the three preceding years, and
a “very small business” as an entity with average gross revenues of $15 million for each of the three
preceding years. 39 The SBA has approved these definitions. 40 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.
16. 700 MHz Guard Bands Licenses. In the 700 MHz Guard Bands Order, the Commission
adopted size standards for “small businesses” and “very small businesses” for purposes of determining
their eligibility for special provisions such as bidding credits and installment payments. 41 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. 42 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. 43 SBA approval of these
definitions is not required. 44 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. 45 Of the 104
licenses auctioned, 96 licenses were sold to nine bidders. Five of these bidders were small businesses that
35

Id.

See “Narrowband PCS Auction Closes,” Public Notice, 16 FCC Rcd 18663 (WTB 2001).

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).
40

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

Id. at 5343 ¶ 108.

Id.

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

See “700 MHz Guard Bands Auction Closes: Winning Bidders Announced,” Public Notice, 15 FCC Rcd 18026
(2000).

Federal Communications Commission

FCC 07-214

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. 46
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). 47 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. 48 Accordingly, at this time there are 54 licenses in
the 700 MHz Guard Bands.
17. 700 MHz Band Commercial Licenses. There is 80 megahertz of non-Guard Band spectrum
in the 700 MHz Band that is designated for commercial use: 698-757, 758-763, 776-787, and 788-793
MHz Bands. With one exception, the Commission adopted criteria for defining two groups of small
businesses for purposes of determining their eligibility for bidding credits at auction. These two
categories are: (1) “small business,” which is defined as an entity that has attributed average annual gross
revenues that do not exceed $15 million during the preceding three years; and (2) “very small business,”
which is defined as an entity with attributed average annual gross revenues that do not exceed $40 million
for the preceding three years. 49 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. 50 The SBA has approved these small size standards. 51
18. 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. 52 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. 53 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. 54

See “700 MHz Guard Bands Auctions Closes: Winning Bidders Announced,” Public Notice, 16 FCC Rcd 4590
(WTB 2001).
47

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

Id.

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

Id. at 1088.

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

See “Lower 700 MHz Band Auction Closes,” Public Notice, 17 FCC Rcd 17272 (WTB 2002).

See “Lower 700 MHz Band Auction Closes,” Public Notice, 18 FCC Rcd 11873 (WTB 2003).

Id.

Federal Communications Commission

FCC 07-214

19. 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.”
20. Advanced Wireless Services. In the AWS-1 Report and Order, the Commission adopted rules
that affect applicants who wish to provide service in the 1710-1755 MHz and 2110-2155 MHz bands. 55
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. 56 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.
21. Broadband Radio Service and Educational Broadband Service. Broadband Radio Service
(“BRS”), formerly known as Multipoint Distribution Service (“MDS”), 57 and Educational Broadband
Service (“EBS”), formerly known as Instructional Television Fixed Service (“ITFS”), 58 use frequencies at
2150-2162 and 2500-2690 MHz to transmit video programming and provide broadband services to
residential subscribers. 59 These services, collectively referred to as “wireless cable,” were originally
designed for the delivery of multichannel video programming, similar to that of traditional cable systems,
but over the past several years licensees have focused their operations instead on providing two-way highspeed Internet access services. 60 We estimate that the number of wireless cable subscribers is
approximately 100,000, as of March 2005. As described below, the SBA small business size standard for
the broad census category of Cable and Other Program Distribution, which consists of such entities

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

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

See 47 C.F.R. Part 21, subpart K; Amendment of Parts 1, 21, 73, 74 and 101 of the Commission’s Rules to
Facilitate the Provision of Fixed and Mobile Broadband Access, Educational and Other Advanced Services in the
2150-2162 and 2500-2690 MHz Bands; Part 1 of the Commission's Rules - Further Competitive Bidding
Procedures; Amendment of Parts 21 and 74 to Enable Multipoint Distribution Service and the Instructional
Television Fixed Service Amendment of Parts 21 and 74 to Engage in Fixed Two-Way Transmissions; Amendment
of Parts 21 and 74 of the Commission's Rules With Regard to Licensing in the Multipoint Distribution Service and
in the Instructional Television Fixed Service for the Gulf of Mexico, 19 FCC Rcd 14165 (2004) (“MDS/ITFS
Order”).

See 47 C.F.R. Part 74, subpart I; MDS/ITFS Order, 19 FCC Rcd 14165.

See Annual Assessment of the Status of Competition in the Market for the Delivery of Video Programming,
Eleventh Annual Report, 20 FCC Rcd 2507, 2565 ¶ 131 (2006) (“2006 Cable Competition Report”).
60

Id.

Federal Communications Commission

FCC 07-214

generating $13.5 million or less in annual receipts, appears applicable to MDS and ITFS. 61 Other
standards also apply, as described.
22. The Commission has defined small MDS (now BRS) entities in the context of Commission
license auctions. In the 1996 MDS auction, 62 the Commission defined a small business as an entity that
had annual average gross revenues of less than $40 million in the previous three calendar years. 63 This
definition of a small entity in the context of MDS auctions has been approved by the SBA. 64 In the MDS
auction, 67 bidders won 493 licenses. Of the 67 auction winners, 61 claimed status as a small business.
At this time, the Commission estimates that of the 61 small business MDS auction winners, 48 remain
small business licensees. In addition to the 48 small businesses that hold BTA authorizations, there are
approximately 392 incumbent MDS licensees that have gross revenues that are not more than $40 million
and are thus considered small entities. 65 MDS licensees and wireless cable operators that did not receive
their licenses as a result of the MDS auction fall under the SBA small business size standard for Cable
and Other Program Distribution. Information available to us indicates that there are approximately 850 of
these licensees and operators that do not generate revenue in excess of $13.5 million annually. Therefore,
we estimate that there are approximately 850 small entity MDS (or BRS) providers, as defined by the
SBA and the Commission’s auction rules.
23. Educational institutions are included in this analysis as small entities; however, the
Commission has not created a specific small business size standard for ITFS (now EBS). 66 We estimate
that there are currently 2,032 EBS licensees, and all but 100 of the licenses are held by educational
institutions. Thus, we estimate that at least 1,932 EBS licensees are small entities.
24. Common Carrier Paging. As noted, the SBA has developed a small business size standard for
wireless firms within the broad economic census category of "Wireless Telecommunications Carriers
(except Satellite)." 67 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. 68 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.” 69 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

13 C.F.R. § 121.201, NAICS code 515210.

MDS Auction No. 6 began on November 13, 1995, and closed on March 28, 1996 (67 bidders won 493 licenses).

47 C.F.R. § 21.961(b)(1).

See ITFS Order, 10 FCC Rcd at 9589.

47 U.S.C. § 309(j). Hundreds of stations were licensed to incumbent MDS licensees prior to implementation of
Section 309(j) of the Communications Act of 1934, 47 U.S.C. § 309(j). For these pre-auction licenses, the
applicable standard is SBA’s small business size standards for “all other telecommunications” (annual receipts of
$23.5 million or less). See 13 C.F.R. § 121.201, NAICS code 517919.
66

In addition, the term “small entity” under SBREFA applies to small organizations (nonprofits) and to small
governmental jurisdictions (cities, counties, towns, townships, villages, school districts, and special districts with
populations of less than 50,000). 5 U.S.C. §§ 601(4)-(6). We do not collect annual revenue data on EBS licensees.
67

13 C.F.R. § 121.201, NAICS code 517211.

13 C.F.R. § 121.201, NAICS code 517210.

13 C.F.R. § 121.201, NAICS codes 517211, 517210.

Federal Communications Commission

FCC 07-214

year. 70 Of this total, 804 firms had employment of 999 or fewer employees, and three firms had
employment of 1,000 employees or more. 71 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. 72
Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of
1,000 employees or more. 73 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.
25. 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. 74 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. 75 The SBA has approved these small business size standards. 76 An auction of
Metropolitan Economic Area licenses commenced on February 24, 2000, and closed on March 2, 2000. 77
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. 78 Of those, we estimate that 360 are small, under the SBA-approved
small business size standard. 79
26. Wireless Communications Service. This service can be used for fixed, mobile, radiolocation,
and digital audio broadcasting satellite uses. The Commission established small business size standards
for the wireless communications services (WCS) auction. 80 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
70

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).
71

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).
73

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.”
74

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, paras. 291-295, 62 FR 16004 (Apr. 3, 1997).

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

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, paras. 98107 (1999).
77

Id. at 10085, para. 98.

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

Id.

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.

Federal Communications Commission

FCC 07-214

approved these small business size standards. 81 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.
27. Wireless Communications Equipment Manufacturers. While these entities are merely
indirectly affected by our action, we see 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. 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.
28. Software Publishers. While these entities are merely indirectly affected by our action, we are
describing them to achieve a fuller record. These companies may design, develop or publish software and
may provide other support services to software purchasers, such as providing documentation or assisting
in installation. The companies may also design software to meet the needs of specific users. The SBA
has developed a small business size standard of $23 million or less in average annual receipts for the
category of Software Publishers. For Software Publishers, Census Bureau data for 2002 indicate that
there were 6,155 firms in the category that operated for the entire year. Of these, 7,633 had annual
receipts of under $10 million, and an additional 403 firms had receipts of between $10 million and $24,
999,999. For providers of Custom Computer Programming Services, the Census Bureau data indicate
that there were 32,269 firms that operated for the entire year. Of these, 31,416 had annual receipts of
under $10 million, and an additional 565 firms had receipts of between $10 million and $24,999,999.
Consequently, we estimate that the majority of the firms in this category are small entities that may be
affected by our action.
29. NCE and Public Broadcast Stations. The Census Bureau defines this category as follows:
“This industry comprises establishments primarily engaged in broadcasting images together with sound.
These establishments operate television broadcasting studios and facilities for the programming and
transmission of programs to the public.” 82 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. 83
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 84 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.
30. In addition, an element of the definition of “small business” is that the entity not be dominant
81

SBA Dec. 2, 1998 Letter.

U.S. Census Bureau, 2002 NAICS Definitions, “515120 Television Broadcasting” (partial definition);
http://www.census.gov/epcd/naics02/def/NDEF515.HTM.
83

13 C.F.R. § 121.201, NAICS code 515120.

“Concerns are affiliates of each other when one concern controls or has the power to control the other or a third
party or parties controls or has to power to control both.” 13 C.F.R. § 21.103(a)(1).

Federal Communications Commission

FCC 07-214

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). 85 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.
31. The Commission has, under SBA regulations, estimated the number of licensed NCE
television stations to be 380. 86 We note, however, that, in assessing whether a business concern qualifies
as small under the above definition, business (control) affiliations 87 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.
D.

Description of Projected Reporting, Recordkeeping, and Other Compliance
Requirements

32. There are potential reporting or recordkeeping requirements proposed in this NPRM. For
example, section 602(b)(2)(A) of the WARN Act requires that CMS providers shall file an election with
the Commission with respect to whether or not it intends to participate in the CMAS. 88 Further,
602(b)(1)(C) of the WARN Act requires CMS providers to provide clear and conspicuous notice to new
and existing customers of the CMS provider’s election not to participate in the CMAS. 89 Further, the
Commission is considering whether to adopt procedures by which CMS providers would log alerts. The
Commission seeks comment on these proposals and especially invited small entity comment. The NPRM
also seeks comment on potential testing procedures for the CMAS that could affect CMS providers as
well as Wireless Communications Equipment Manufacturers. Finally, section 602(b)(2) requires that
CMS providers undertake a procedure to elect whether or not to provide alerts to their customers. The
proposals set forth in the NPRM are intended to advance our public safety mission and establish an
effective CMAS in a manner that imposes minimal regulatory burdens on affected entities.
E.

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

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

FCC News Release, “Broadcast Station Totals as of September 30, 2005.”

See Broadcast Station Totals, supra IRFA note 11.

“[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).
88

WARN Act, § 602(b)(2)(A).

WARN Act, § 602(b)(1)(C).

Federal Communications Commission

FCC 07-214

entities.” 90
34. As noted in paragraph 1 above, this NPRM initiates a comprehensive rulemaking to establish
a system by which CMS providers may elect to transmit emergency alerts to the public, a goal mandated
by recent legislation and consistent with the Commission’s obligation to protect the lives and property of
Americans. In commenting on the manner in which the Commission seeks in this NPRM to achieve this
goal, commenters are invited to propose steps that the Commission may take to minimize any significant
economic impact on small entities. When considering proposals made by other parties, commenters are
invited to propose significant alternatives that serve the goals of these proposals

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

35.

None.

5 U.S.C. § 603(c)(1) – (c)(4).

Federal Communications Commission

APPENDIX B

Commercial Mobile Service Alert Advisory Committee
Commercial Mobile Alert Service Architecture and Requirements

FCC 07-214

Commercial Mobile Alert
Service Architecture and
Requirements

Date

10/12/2007

All marks, trademarks, and product names used in this document are the property of their respective owners.

Commercial Mobile Alert Service Architecture and Requirements

Table of Contents
1

INTRODUCTION AND EXECUTIVE SUMMARY.......................................................................................6
1.1
Executive Summary....................................................................................................................................6
1.1.1
Reference Architecture (Section 2)........................................................................................................6
1.1.2
Deployment Scenarios (Section 3).........................................................................................................7
1.1.3
CMAS Alert Scenarios (Section 4)........................................................................................................7
1.1.4
General Recommendations and Conclusions (Section 5) ......................................................................7
1.1.5
Service Profiles (Section 6) ...................................................................................................................8
1.1.6
Mobile Device Functionality for CMAS Alerts (Section 7) ..................................................................8
1.1.7
Security for CMAS Alerts (Section 8)...................................................................................................8
1.1.8
CMAS Reliability & Performance (section 9) .......................................................................................9
1.1.9
Interface Protocols for CMAS Alerts (Section 10) ................................................................................9
1.2
Definitions ..................................................................................................................................................9
1.3
Acronyms ...................................................................................................................................................9

REFERENCE ARCHITECTURE ...................................................................................................................11
2.1
Functional Reference Model Diagram......................................................................................................11
2.2
Government Administered Elements Definitions & Requirements..........................................................11
2.2.1
Reference Point A................................................................................................................................11
2.2.2
Alert Aggregator..................................................................................................................................11
2.2.3
Reference Point B ................................................................................................................................12
2.2.4
Alert Gateway......................................................................................................................................12
2.2.4.1 General Alert Gateway System Requirements................................................................................12
2.2.4.2 CMSP Profile Support ....................................................................................................................13
2.3
CMSP Administered Elements Definitions & Requirements ...................................................................13
2.3.1
Reference Point C ................................................................................................................................13
2.3.2
CMSP Gateway ...................................................................................................................................14
2.3.3
CMSP Infrastructure ............................................................................................................................15
2.3.4
Reference Points D & E.......................................................................................................................15
2.3.5
Mobile Device .....................................................................................................................................15

DEPLOYMENT SCENARIOS ........................................................................................................................17
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
3.2.3
3.3
3.4
3.4.1
3.4.2

Scenarios for Single Technology Deployed .............................................................................................18
Scenario – CMAS in Entire Single Technology Operator Network on All Devices ...........................18
Scenario – CMAS in Entire Single Technology Operator Network on a Subset of Devices...............19
Scenario – CMAS in Subset of Single Technology Operator’s Network on All Devices ...................20
Scenario – CMAS in Subset of Single Technology Operator’s Network on Subset of Devices..........21
Scenarios for Multiple Technologies Deployed .......................................................................................22
Scenario – CMAS in Entire Multiple Technology Operator Network on All Devices........................22
Scenario – CMAS in Entire Multiple Technology Operator Network on Subset of Devices ..............23
Scenario – CMAS in Subset of Multiple Technology Operator Network on Subset of Devices .........24
Scenario for Operator Does Not Elect to Transmit CMAS Alerts............................................................25
Subscriber Notification Recommendations ..............................................................................................25
Notification Procedures .......................................................................................................................25
Notification Text Recommendations ...................................................................................................25

CMAS ALERT SCENARIOS...........................................................................................................................27
4.1
Nominal CMAS Alert Scenarios ..............................................................................................................27
4.1.1
Scenario for Nominal Text CMAS Alert .............................................................................................27
4.1.1.1 Pre-Conditions ................................................................................................................................27
4.1.1.2 Normal Flow ...................................................................................................................................27
4.1.2
Scenario for Nominal Streaming Audio or Streaming Video CMAS Alert.........................................29
4.1.3
Scenario for Nominal Downloaded Multimedia CMAS Alert.............................................................30
4.2
CMAS Alert Cancellation Scenario..........................................................................................................30
4.2.1
Pre-Conditions .....................................................................................................................................30
2

Commercial Mobile Alert Service Architecture and Requirements

4.2.2
Normal Flow........................................................................................................................................30
4.3
CMAS Alert Update Scenarios.................................................................................................................33
4.3.1
Scenario for Update of Text CMAS Alert ...........................................................................................33
4.3.1.1 Pre-Conditions ................................................................................................................................33
4.3.1.2 Normal Flow ...................................................................................................................................33
4.3.2
Scenario for Update of Streaming Audio or Streaming Video CMAS Alert .......................................36
4.3.3
Scenario for Update of Downloaded Multimedia CMAS Alert...........................................................36
4.4
CMAS Alert Expiration Scenario.............................................................................................................36
4.4.1
Pre-Conditions .....................................................................................................................................36
4.4.2
Normal Flow........................................................................................................................................36
4.5
Duplicate CMAS Alerts Scenarios ...........................................................................................................37
4.5.1
Scenario for Duplicate CMAS Alerts on Same Broadcast Technology...............................................37
4.5.1.1 Pre-Conditions ................................................................................................................................37
4.5.1.2 Normal Flow ...................................................................................................................................37
4.5.2
Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies.......................................38
4.5.2.1 Pre-Conditions ................................................................................................................................38
4.5.2.2 Normal Flow ...................................................................................................................................39
4.6
Multiple Different Active CMAS Alerts Scenario ...................................................................................42
4.6.1
Pre-Conditions .....................................................................................................................................42
4.6.2
Normal Flow........................................................................................................................................42
5

GENERAL REQUIREMENTS & CONCLUSIONS .....................................................................................46
5.1
Scope & Definition of CMAS Alerts........................................................................................................46
5.2
General CMAS Requirements & Conclusions .........................................................................................47
5.3
Recommendations for Alert Initiation & Alert Initiators..........................................................................48
5.3.1
CMAM Elements.................................................................................................................................48
5.3.2
Generating CMAM from CAP Fields..................................................................................................48
5.3.2.1 Generating CMAM from Free Form Text.......................................................................................51
5.3.3
Presidential Message and AMBER Alert.............................................................................................51
5.3.4
Recommended Message Initiator Training ..........................................................................................52
5.4
Recommendations for Geo-Targeting of CMAS Alerts ...........................................................................52
5.5
Requirements and Recommendations on Needs of Users, Including Individuals with Disabilities and the
Elderly 53
5.5.1
General Requirements..........................................................................................................................53
5.5.2
User Needs Requirements....................................................................................................................54
5.5.2.1 Alert/Attention Signal .....................................................................................................................54
5.5.2.2 Message Content.............................................................................................................................54
5.5.2.3 Output Mode/Display......................................................................................................................54
5.5.2.4 Behavior on Receipt of a Message..................................................................................................55
5.5.2.5 CMAS-Related Print and Online Materials ....................................................................................56
5.5.3
Subscriber CMA Opt-Out Recommendations .....................................................................................56
5.6
Recommendations for CMAM Transmissions .........................................................................................57
5.7
Multi-Language CMAS Alerts Recommendations...................................................................................57
5.8
CMAS Reception Control on Mobile Devices .........................................................................................58
5.9
Roaming ...................................................................................................................................................59

SERVICE PROFILES.......................................................................................................................................60
6.1
6.2
6.3
6.4
6.5

Conclusions on Text, Audio, Video & Multimedia Resources.................................................................60
Text Profile...............................................................................................................................................61
Streaming Audio Profile (future capability) .............................................................................................61
Streaming Video Profile (future capability) .............................................................................................62
Downloaded Multimedia Profile (future capability).................................................................................63

MOBILE DEVICE FUNCTIONALITY FOR CMAS ALERTS...................................................................64
7.1
7.2
7.3

General Requirements on Mobile Device Functionality ..........................................................................64
Mobile Device Audio Attention Signal & Vibration Cadence Recommendations...................................64
CMAS Functionality on Mobile Device...................................................................................................65
3

Commercial Mobile Alert Service Architecture and Requirements

7.4
8

Impact to Mobile Device Battery Life......................................................................................................66

SECURITY FOR CMAS ALERTS..................................................................................................................68
8.1
8.1.1
8.1.2
8.2
8.3
8.4

Alert Interface & Aggregator Trust Model...............................................................................................68
Trust Model Definitions.......................................................................................................................68
Trust Model Requirements ..................................................................................................................68
Alert Gateway Security Requirements .....................................................................................................69
Reference Point C Security.......................................................................................................................69
Reference Points D & E Security .............................................................................................................69

CMAS RELIABILITY & PERFORMANCE .................................................................................................70
9.1
9.2
9.3
9.4
9.4.1
9.5
9.5.1
9.5.2

Alert Gateway Performance Requirements ..............................................................................................70
Alert Delivery Latency .............................................................................................................................71
CMAS End-to-End Reliability .................................................................................................................71
Message Logging......................................................................................................................................72
Alert Gateway Logging .......................................................................................................................72
CMAS Testing..........................................................................................................................................72
General CMAS Testing Recommendations.........................................................................................73
Alert Gateway Testing .........................................................................................................................73

INTERFACE PROTOCOLS FOR CMAS ALERTS.................................................................................75

10.1
Reference Point A Protocol ......................................................................................................................75
10.2
Reference Point B Protocol ......................................................................................................................75
10.3
Alert Gateway Interfaces & Mapping Requirements................................................................................76
10.3.1 Alert Gateway Interface Requirements................................................................................................76
10.3.2 Alert Gateway Interface Mapping Requirements ................................................................................76
10.4
Reference Point C Protocol ......................................................................................................................82
10.4.1 Structure of the CMA “C” Reference Point Protocol ..........................................................................84
10.4.2 CMAC Data Dictionary .......................................................................................................................85
10.4.2.1
CMAC_Alert_Attributes Segment .............................................................................................85
10.4.2.2
CMAC_Alert_Info Segment ......................................................................................................87
10.4.2.3
CMAC_Area Segment: ..............................................................................................................91
10.4.2.4
CMAC_Resource Segment: .......................................................................................................92
10.4.3 Example CMAC XML Schema ...........................................................................................................93
10.4.4 Element Mapping from B Reference Point (CAP) to C Reference Point (CMAC) to E Reference
Point (CMAE) Elements......................................................................................................................................96
10.4.5 Definition of CMAC_cmas_geocode Element ....................................................................................98
10.4.6 Definition of CMAC Response Codes...............................................................................................100
10.4.7 Example CMAS “C” Interface Alert Messages ................................................................................101
10.5
Reference Point E Protocols ...................................................................................................................102
11

ANNEX A – ANTICIPATED PEAK & AVERAGE CMAS TRAFFIC VOLUME ..............................104

ANNEX B – WARN ACT STATUTORY REQUIREMENTS ................................................................107

12.1
WARN Act Requirements ......................................................................................................................107
12.2
WARN Act Interpretations.....................................................................................................................108
12.2.1 CMSP Election ..................................................................................................................................108
12.3
Licensees and Permittees of Noncommercial Educations Broadcasting Stations or Public Television
Stations 109

Commercial Mobile Alert Service Architecture and Requirements

List of Figures
Figure 2-1
Figure 3-1
Figure 3-2
Figure 3-3
Figure 3-4
Figure 3-5
Figure 3-6
Figure 3-7
Figure 3-8
Figure 4-1
Figure 4-2
Figure 4-3
Figure 4-4
Figure 4-5
Figure 4-6
Figure 4-7
Figure 10-1
Figure 10-2
Figure 12-1

CMAS Functional Reference Model....................................................................................................11
CMAS in Entire Single Technology Network on All Devices ............................................................18
CMAS in Entire Network on Sub-set of Devices ................................................................................19
CMAS in Subset of Single Technology Operator’s Network on All Devices .....................................20
CMAS in Subset of Single Technology Operator’s Network on Subset of Devices ...........................21
CMAS in Entire Multiple Technology Operator Network on All Devices..........................................22
CMAS in Entire Multiple Technology Operator Network on Subset of Devices ................................23
CMAS in Subset of Multiple Technology Operator Network on Subset of Devices...........................24
Operator Does Not Elect to Transmit CMAS Alerts ...........................................................................25
Flow for Scenario for Nominal Text CMAS Alert ..............................................................................29
Flow for CMAS Alert Cancellation Scenario ......................................................................................32
Flow for Scenario for Update of Text CMAS Alert ............................................................................35
Flow for CMAS Alert Expiration Scenario .........................................................................................37
Flow for Scenario for Duplicate CMAS Alerts on Same Broadcast Technology ................................38
Flow for Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies........................41
Flow for Scenario for Multiple Different Active CMAS Alerts Scenario ...........................................45
Relationship of CAP Elements to Reference Point C Elements......................................................82
CMAC Message Structure ..............................................................................................................84
Potential Deployment Timeline ....................................................................................................109

List of Tables
Table 2-1
Table 5-1
Table 6-1
Table 6-2
Table 6-3
Table 6-4
Table 10-1
Table 10-2
Table 10-3
Table 10-4
Table 10-5
Table 10-6
Table 10-7
Table 10-8
Table 11-1
Table 11-2
Table 11-3

CMSP Profile on Alert Gateway..........................................................................................................13
CAP Value Field Mapping to Text ......................................................................................................49
Text Profile ..........................................................................................................................................61
Streaming Audio Profile ......................................................................................................................61
Video Profile........................................................................................................................................62
Downloaded Multimedia Profile..........................................................................................................63
Parameter mapping from “B” Interface CAP message in to “C” Interface CMAC message...............79
CMAC_Alert_Attributes Segment.......................................................................................................85
CMAC_Alert_Info Segment................................................................................................................87
CMAC_Area Segment.........................................................................................................................91
CMAC_Resource Segment..................................................................................................................92
Mapping Reference Point B Elements to Reference Point C Elements ...............................................96
CMAC_cmas_geocode Assignments...................................................................................................99
Reference Point E Protocol Elements ................................................................................................102
Table of Total 2006 Tornado & Flash Flood Warnings by State.......................................................105
Table of 2006 Tornado & Flash Flood Warnings by State by Month................................................106
Estimated CMA Volume by Month ...................................................................................................106

Commercial Mobile Alert Service Architecture and Requirements

1 Introduction and Executive Summary

1.1

Executive Summary

4
5
6
7
8
9
10
11
12

On October 13, 2006, the President signed the Security and Accountability For Every Port (SAFE Port)
Act 1 into law. Title VI of the SAFE Port Act, the Warning, Alert and Response Network (WARN) Act,
2
establishes a process for Commercial Mobile Service Providers (CMSPs) to voluntarily elect to transmit
emergency alerts. Section 603 (c) of the WARN Act required that the Federal Communications
Commission (Commission) establish the Commercial Mobile Service Alert Advisory Committee
(CMSAAC) to develop and recommend technical standards and protocols for the voluntary transmission of
emergency alerts by CMSPs within one year from the date of enactment of the WARN Act. (i.e., by
October 12, 2007). 3 This document presents the result of the CMSAAC’s efforts to satisfy the obligations
set forth in the WARN Act.

13
14
15

The WARN Act places the following tasks before the CMSAAC. Each is followed by the section number
or numbers in this report that includes recommendations addressing the associated WARN Act’s
requirements:

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Within one year after the enactment of this Act, the Advisory Committee shall develop and submit to the
Federal Communications Commission recommendations –

39
40
41
42

Following are summaries of each section in the document, with a focus on the recommendations the
CMSAAC makes in each. This section is provided as a high-level overview only and is not intended as a
substitute for the formal recommendations of the CMSAAC, many of which are highly technical and are
laid forth in detail in subsequent sections of the document.

1) For protocols, technical capabilities, and technical procedures through which electing commercial
mobile service providers receive, verify, and transmit alerts to subscribers (Sections 2, 4, 6, 8, 10);
2) For the establishment of technical standards for priority transmission of alerts by electing
commercial mobile service providers to subscribers (Sections 2, 9);
3) For relevant technical standards for devices and equipment and technologies used by electing
commercial mobile service providers to transmit emergency alerts to subscribers (Sections 7, 9);
4) For the technical capability to transmit emergency alerts by electing commercial mobile service
providers to subscribers in languages in addition to English, to the extent practicable and feasible
(Section 5);
5) Under which electing commercial mobile service providers may offer subscribers the capability of
preventing the subscriber’s device from receiving emergency alerts, or classes of such alerts,
(other than an alert issued by the President), consistent with Section 602(b)(2)(E) of the WARN
Act (Section 5);
6) For a process under which commercial mobile service providers can elect to transmit emergency
alerts if
a) not all of the devices or equipment used by such provider are capable of receiving such alerts
(Section 3); or
b) the provider cannot offer such alerts throughout the entirety of its service area (Section 3); and
7) As otherwise necessary to enable electing commercial mobile service providers to transmit
emergency alerts to subscribers.

1.1.1

43
44

Reference Architecture (Section 2)

This section recommends a functional reference model for the distribution of alerts to Commercial Mobile
1

Security and Accountability For Every Port Act of 2006 (SAFE Port Act), Pub.L. 109-347.
Safe Port Act, Title VI-Commercial Mobile Service Alerts.
3
WARN Act, §603(c).
2

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7

Service Providers (CMSPs) (Section 2.1). Under this reference model, a Federal government entity, the
“Alert Aggregator,” would receive, aggregate, and authenticate alerts originated by authorized alert
initiators using the Common Alerting Protocol (CAP). The government entity would also act as an “Alert
Gateway” (Section 2.2) to formulate a 90 character alert based on key fields in the CAP alert sent by the
alert initiator 4. Based on CMSP profiles maintained in the Alert Gateway, the Alert Gateway would then
deliver the alert over a secure interface (see Section 2.3.1) to another gateway maintained by the
appropriate CMSP “CMSP Gateway.” (Section 2.3.2)

8
9
10
11
12
13
14
15
16

Each individual CMSP Gateway would be responsible for the management of the particular CMSP
elections to provide alerts in whole or in part. The CMSP Gateway would also be responsible for
formulating the alert in a manner consistent with the individual CMSP’s available delivery technologies,
mapping the alert to the associated set of cell sites / paging transceivers, and handling congestion within the
CMSP Infrastructure. The CMSP Gateway will process alerts in a first in – first out (FIFO) queuing
method except for a Presidential-level alert, which will be immediately moved to the top of the queue and
processed before all other non-Presidential alerts. The CMSAAC or its successor will study the feasibility
of establishing a procedure that, if invoked, would give certain messages priority status irrespective of their
ranking in the Alert Gateway queue.

17
18
19
20
21
22
23
24

Upon receipt of an alert from the CMSP Gateway, the CMSP Infrastructure distributes the received CMAS
alert message to the determined set of cell sites/paging transceivers and authenticates interactions with the
Mobile Device (Section 2.3.3). Ultimately, the alert is received on a customer’s Mobile Device. The major
functions of the Mobile Device are to authenticate interactions with the CMSP Infrastructure, to monitor
for CMAS alerts, to maintain customer options (such as the subscriber’s opt-out selections and subscriber’s
preferred language, if applicable), 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. (Section 2.3.5.)

1.1.2

25
26
27
28
29
30
31
32
33

Deployment Scenarios (Section 3)

This section notes that the WARN Act specifies that a CMSP who elects to transmit emergency alerts can
elect to transmit the CMAS alerts “in whole or in part.” 5 The CMSAAC defines “in whole or in part” as
including all or a subset of the CMSP’s service area, and/or all or a subset of current and future mobile
devices supported by the CMSP network. The section then posits a set of scenarios in which an individual
alert is sent over CMSP networks that deploy various technologies and handsets that may or may not
support the transmission of the alert. (Sections 3.1-3.3). This section also contains recommendations for
the notices to subscribers that the WARN Act requires where a CMSP does not elect to provide alerts.
(Section 3.4).

1.1.3

34
35
36
37
38

CMAS Alert Scenarios (Section 4)

This section provides descriptions of a representative sample of scenarios and message flows related to the
transmission and support of CMAS Alerts. The section includes descriptions and charts of scenarios
involving text based streaming audio or streaming video CMAS alert, CMAS alert cancellation, CMAS
alert updates, CMAS alert expiration, duplicate CMAS alerts, and multiple different active CMAS alerts.

1.1.4

39
40
41
42
43
44
45
46

General Recommendations and Conclusions (Section 5)

This section sets forth the CMSAAC’s recommendations concerning the extent and scope of CMAS alerts.
The major recommendation in this section is that there should be three classes of Commercial Mobile
Alerts (CMAs): Presidential-level, Imminent threat to life and property; and Child Abduction Emergency
or “AMBER Alert” Service (Section 5.1). The section also recommends a format for CMAS alerts (se
Section 5.3.1.) and a method for extracting a CMAS alert from CAP fields and free form text (Section
5.3.2.). The section also recommends that alert initiators be trained on creating CMAS alerts (Section
5.3.4).
4

Provisions have also been made for authorized alert originators to formulate and distribute alerts via the Alert
Gateway in free text. See e.g., section 5.3.2, supra.
5
WARN Act, §602(c).
7

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8

A significant recommendation concerns the geo-targeting of CMAS alerts. The CMSAAC acknowledges
that it is the goal of the CMAS for CMSPs to be able to deliver geo-targeted alerts to the areas specified by
the alert initiator. However, early CMAS implementations will likely be limited to static geo-targeting
areas. Hence, the CMSAAC recommends that, initially, geo-targeting be at least precise enough to target at
the county level. The CMSAAC further recognizes that certain areas with especially urgent alerting needs
have a need for more precise geo-targeting, and provisions are made to accommodate them. Longer term
the CMSAAC recommends that provisions in Section 604 of the WARN Act be applied to fully realize the
benefits of dynamic geo-targeting.

9
10
11
12
13
14

This section also makes recommendations on the needs of users, including individuals with disabilities and
the elderly. Among the major recommendations is the requirement for the CMAS to support a common
audio attention signal and a common vibrating cadence to be used solely for CMAS alerts. Further, the
CMSAAC recommends that the alert initiator use clear and simple language whenever possible, with
minimal use of abbreviations and that the mobile devices provide an easy way to allow the user to recall the
message for review.

15
16
17
18
19
20
21
22
23
24

The section notes that the WARN Act provides for subscriber CMAS alert Opt-Out, and recommends that
CMSPs shall offer their subscribers a simple opt-out process that is based on the classification of imminent
threat and AMBER Alerts. Except for presidential messages, which are always transmitted, the process
should allow the choice to opt-out of (1) All messages, (2) All severe messages, or (3) AMBER Alerts.
Regarding the transmission of CMAS alerts in languages other than English, the CMSAAC has analyzed
the technical feasibility of supporting multi-language CMAS alerts on various delivery technologies and
has determined that support of languages other than English is a very complex issue and that, at the present
time, the CMSAAC believes there are fundamental technical problems to reliably implement any languages
in addition to English. The CMSAAC recommends, however, that the biennial review committee continue
to study the feasibility of supporting additional languages, as technology evolves.

Finally, the CMSAAC notes that roaming is only supported on an intra-technology basis.

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

1.1.5

Service Profiles (Section 6)

In this section the CMSAAC notes that the CMAS architecture and recommendations are based upon the
principles of technology-neutral service profiles containing, for example, profiles for maximum payload
and displayable message size. The section defines service profiles for: (a) Text; (b) Streaming Audio
(future capability); (c) Streaming Video (future capability); and (c) Downloaded Multimedia Profile (future
capability), and provides general recommendations and conclusions for each.

1.1.6

Mobile Device Functionality for CMAS Alerts (Section 7)

This section describes the impact to the mobile devices. i.e. the handsets, for the support of CMAS alerts.
The section includes the recommendation that if the end user has both muted the mobile device audio and
alarms and/or has deselected or turned off the vibration capabilities of the mobile device, neither the CMAS
audio attention signal nor the special emergency alert vibration cadence will be activated upon receipt of a
CMAS alert. Further, the section recommends that, in order to minimize the possibility of network
congestion and false alerts, mobile devices should not support any user interface capabilities to forward
received CMAS alerts, to reply to received CMAS alerts, or to copy and paste CMAS alert contents. The
section also notes that the monitoring for CMAS alerts could have a significant impact on handset battery
life, but that with modifications to network infrastructure, mobile devices and/or standards, the reduction of
battery life can be less than 10% of today’s capability for monitoring.

1.1.7

Security for CMAS Alerts (Section 8)

This section recommends a specific Alert Aggregator and Alert Gateway Trust Model to assure the
security, authentication and authorization of alerts from the Alert initiator to the CMSP Gateway. The
section then recommends security requirements for the interface between the Alert and CMSP Gateways
and within each CMSP’s network.

Commercial Mobile Alert Service Architecture and Requirements

1.1.8

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CMAS Reliability & Performance (section 9)

Recommendations in this section include Alert Gateway performance requirements such as 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. The CMSAAC acknowledges the importance of assessing any
latency in alert delivery, but notes that it will be difficult to predict system performance in this area prior to
deployment. The CMSAAC suggests that factors relevant to potential latency include; 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. Similarly, although the CMSAAC recommends that the CMAS end-to-end reliability
technology meet telecom standards for highly reliable systems, 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. In order to assure the reliability and performance of this new system,
the CMSAAC recommends procedures for logging CMAS alerts at the Alert Gateway and for testing the
system at the Alert Gateway and on and end-to-end basis.

1.1.9

17
18
19
20
21

Interface Protocols for CMAS Alerts (Section 10)

This section establishes detailed technical protocols and specifications for the delivery of alerts over the
various interfaces in the Reference Model. Specifically, the section established requirements that Alert
Initiators must meet to deliver CMAS alerts to the Alert Aggregator, and that the Alert Gateway must meet
to delver CMAS alerts to the CMSP gateway. CAP mapping parameters are provided in detail.

1.2

Definitions

24
25
26

Commercial Mobile Alert (CMA) – The term CMA refers to the event that creates the need for a CMAM
and can fall into any of the following three categories: i) a Presidential alert, ii) an imminent threat to life
and property, or iii) an AMBER alert.

27
28
29

Commercial Mobile Alert Message (CMAM) – The term CMAM refers to communication that is issued
to the end-user via the Commercial Mobile Alerting System in response to i) a Presidential alert, ii) an
imminent threat to life and property, or iii) an AMBER alert.

30
31

Commercial Mobile Alert Service (CMAS) – The term CMAS refers to the end-to-end architecture for
delivery emergency alert messages subject to the WARN Act.

32
33
34
35

Commercial Mobile Service Provider (CMSP) – Per the WARN Act Section 602 (b) (1) (A), a CMSP is
a 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) ), where the term "commercial mobile service" means any mobile
service that is provided for profit and makes interconnected service available. 6

1.3

Acronyms

AMBER...........................................America's Missing: Broadcast Emergency Response

CAP .................................................Common Alerting Protocol as defined in CAP version 1.1 specification

CDMA.............................................Code Division Multiple Access

CMA................................................Commercial Mobile Alert

CMAM ............................................Commercial Mobile Alert Message

CMAS .............................................Commercial Mobile Alert Service

CMSAAC........................................Commercial Mobile Service Alert Advisory Group
6

WARN Act, §602(b)(1(A).
9

Commercial Mobile Alert Service Architecture and Requirements

CMSP ..............................................Commercial Mobile Service Provider

CTIA ...............................................Cellular Telecommunications Industry Association

EOC.................................................Emergency Operations Center

FIPS.................................................Federal Information Processing Standards

GNIS ...............................................Geographic Names Information System

GSM ................................................Global System for Mobile communications

NOAA .............................................National Oceanic and Atmospheric Administration

MVNO.............................................Mobile Virtual Network Operator

NIST................................................National Institute of Standards and Technology

NWS................................................National Weather Service

SAME..............................................Specific Area Message Encoding

SMS.................................................Short Message Service

UMTS..............................................Universal Mobile Telecommunications System

VPN.................................................Virtual Private Network

WARN.............................................Warning, Alert, and Response Network

XML................................................Extensible Markup Language

Commercial Mobile Alert Service Architecture and Requirements

1
2

2 Reference Architecture
2.1

Functional Reference Model Diagram
A

Proposed Government Administered

CMSP

Federal
Agencies
B
CMSP

Alert
Aggregator
Alert
Gateway

Local EOC

Mobile

State EOC

3
4
5

Figure 2-1

2.2

CMAS Functional Reference Model

Government Administered Elements Definitions &
Requirements

6
7
8
9
10

The CMSAAC recommends that the Alert Aggregator and Alert Gateway be the responsibility of the
authorized government entity. The CMSAAC further recommends that the system be acquired, managed,
operated, and administered by the same authorized government entity.

11
12

2.2.1

Reference Point A

The actions to be performed at Reference Point A include the following:

Provide information for the authentication and validation of actions across this reference point.

15
16

Delivery of a new, updated, or cancelled wireless alert message to Alert Distribution Network in CAP
format.

17
18

Acknowledgement from Alert Gateway to Alert Aggregator that the new, updated, or cancelled
wireless alert message has been received by the Alert Gateway.

19
20
21
22
23
24

2.2.2

Alert Aggregator

The CMSAAC recommends that the authorized government entity operate an alerting framework that
aggregates all alerts submitted by Federal, State, Tribal and local originators and deliver these alerts to the
Alert Gateway. The CMSAAC makes the following additional recommendations regarding the Alert
Aggregator:
11

Commercial Mobile Alert Service Architecture and Requirements

1
2

All message originators will comply with the Trust Model when sending messages through the alert
framework to the Alert Gateway. (See Section 8.1, below for a discussion of the Trust Model)

The Alert Aggregator will be operated according to the requirements set forth in the Trust Model.

The authorized government entity will publish open non-proprietary standards for message origination

The Alert Aggregator will utilize CAP as the messaging standard to the Alert Gateway.

6
7

Messages will be delivered to the Alert Gateway on a first-in first-out basis, with the exception of the
Presidential message, which will move to the front of any existing messages.

8
9

The Alert Aggregator will support bi-directional message traffic to deliver the message and to notify
the alert message originator of the status of its CMAS message.

10
11

The Alert Aggregator may consist of separate paths for the delivery of the message to the Alert
Gateway and from the Alert Gateway for message status notification.

2.2.3

Reference Point B

The actions to be performed by Reference Point B include the following:

Carry forward information for the authentication and validation of actions across this reference point.

Delivery of a new, updated, or cancelled wireless alert message to Alert Gateway in CAP format.

16
17

Carry acknowledgement from Alert Gateway to Alert Aggregator that the new, updated, or cancelled
wireless alert message has been received.

2.2.4

Alert Gateway

2.2.4.1

General Alert Gateway System Requirements

19
20
21

The functions to be performed by the Alert Gateway include the following:

Ensure authenticity of interactions with the Alert Aggregator and the CMSP Gateway.

Validate (e.g., authentication and non-repudiation) the received wireless alert message.

24
25

Maintain a log of wireless alert messages received from the Alert Aggregator and delivered to and
rejected by the CMSP Gateway.

26
27

Implementation and support of defined ‘service profiles’ specifying alert message formats containing
information elements required by CMSPs for the delivery of alert messages to wireless devices.

28
29
30

Stores CMSPs profiles including the CMSP election within a specific service area, supported
technologies including any associated service profiles, characteristics, restrictions, limitations, or
parameters.

Deployment to achieve geographic separation from the CMSP Gateway.

Support interfacing with multiple CMSPs and with multiple CMSP Gateways per CMSP.

Geographically redundant Alert Gateway to avoid a single point of failure.
12

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

2.2.4.2

CMSP Profile Support

The CMSAAC recommends that the Alert Gateway have a profile for every CMSP. The CMSAAC further
recommends that these profiles be administered using the following procedures:

4
5
6

•

The CMSP Gateway IP addresses and CMSP service area on a state level will be provided by an
authorized CMSP representative to the Alert Gateway administrator 30 days in advance of the
required in-service date when CMSP begin to transmit the CMAMs.

7
8

•

Any updates of CMSP profile will be provided by an authorized CMSP representative to the Alert
Gateway administrator in writing at least 30 days in advance of the required in-service date.

•

The parties will negotiate and mutually agree on an implementation date.

Table 2-1
Profile Parameter

CMSP Profile on Alert Gateway

Parameter Election

CMSP Name

Description
Unique identification of CMSP

CMSP Gateway Address

Geo-Location Filtering

IP address or Domain Name
Alternate IP address

Optional and subject to implementation

If “yes” the only CMAM issued in the
listed states will be sent to the CMSP
Gateway.
If “no”, all CMAM will be sent to the
CMSP Gateway.

If yes, list of states

CMAC Geocode for state

List can be state name, abbreviated state
name, or CMAC GeoCode for state (see
Section 10.4.5)

11
12

2.3

CMSP Administered Elements Definitions &
Requirements

2.3.1

Reference Point C

13
14
15

The CMSAAC recommends that the actions to be performed by Reference Point C include the following:

Provide information for the authentication and validation of actions across this reference point.

17
18
19

Delivery of a new, updated, or cancelled wireless alert message by the Alert Gateway in a format that
is suitable for the mobile devices and the wireless alert delivery technology or technologies
implemented by the CMSP.

20
21

Acknowledgement from CMSP Gateway to Alert Gateway that the new, updated, or cancelled wireless
alert message has been received by the CMSP Gateway.

Commercial Mobile Alert Service Architecture and Requirements

2.3.2

CMSP Gateway

2
3

The CMSAAC recommends that the functions to be performed by the Commercial Mobile Service
Provider Gateway include the following:

Authentication of interactions with the Alert Gateway.

5
6

Management of Commercial Mobile Service Provider elections to support CMAS alert services within
the Commercial Mobile Service Provider’s service areas.

Determination if CMSP has elected to offer CMAS alert services within the specified alerting area.

8
9

Determination of which delivery technology or delivery technologies will be utilized for the
transmission of CMAS alert messages within the specified alerting area.

Map the alert area of the CMAS alert message into the associated set of cell sites / paging transceivers.

11
12

Manage and execute CMAS alert retransmission subject to delivery technology capability and CMSP
policy.

13
14

A CMSP that elects to transmit alerts will have one or more CMSP Gateways designated for receipt of
alerts from the Alert Gateway.

15
16

The CMSP Gateway should have redundancy and be designed to provide high reliability and
availability comparable to similarly situated network elements.

17
18
19

A Commercial Mobile Service Provider may have one or more CMSP Gateways in the CMSP network
to support regional distribution of CMSA messages and to handle anticipated CMAM traffic levels.
The CMSP has the responsibility for the distribution of the CMAM traffic among CMSP Gateways.

10. CMSP Gateway(s) in a CMSP network will be identified by a unique IP address or domain name.

21
22

11. The CMSP Gateway will support the defined CMAS “C” interface and associated protocols between
the Alert Gateway and the CMSP Gateway.

23
24

12. The interface from the CMSP Gateway to the CMSP Infrastructure is CMSP and technology dependent
and is not specified in CMAS.

25
26
27

13. The CMSP Gateway model will support standardized IP based security mechanisms such as a firewall.
The CMSP will provide a secure connection from the CMSP Gateway to the Alert Gateway for
reception of the CMAS messages.

14. The CMSP Gateway application will support CMAM:

Authentication

Message integrity

Availability (i.e. keep alive messages)

32
33
34
35

15. The CMSP Gateway will support a mechanism on the Reference Point C interface with the Alert
Gateway to stop and start alert message deliveries from the Alert Gateway to the CMSP Gateway
under conditions such as the event too many messages are being received on the interface, the CMSP
Gateway buffers are full, congestion exists at the CMSP Gateway, etc.

36
37

16. The CMSP Gateway will support a mechanism to handle congestion within the CMSP Infrastructure
according to CMSP policy.

38
39

17. The CMSP Gateway will not be responsible for performing any formatting, re-formatting, or
translation of the CMAM other than the following:

40
41
42
43

Text, audio, video, and multimedia files may require transcoding into the proper format (e.g.,
codec) supported by the mobile device.

18. The CMSP Gateway will be responsible for validating message integrity and alerting parameters and
respond with an error message to the Alert Gateway if these validations fail.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

19. The CMSP Gateway will retrieve any resources (e.g., audio, video, multimedia files such as graphics)
from the Alert Gateway if the alert attributes indicate a resource is available and if the CMSP has the
capability to broadcast these resource types.

4
5
6
7
8

20. The CMSP Gateway will process CMAMs in a first in – first out (FIFO) queuing method except for a
Presidential-level alert which will be immediately moved to the top of the queue and processed before
all other non-Presidential alerts. The CMSAAC or its successor will study the feasibility of
establishing a procedure that, if invoked, would give certain messages priority status irrespective of
their ranking in the Alert Gateway queue.

2.3.3

CMSP Infrastructure

10
11
12

CMSP infrastructure functionality is generally dependent on delivery technology, the capabilities of the
delivery technology, and mobile vendor/CMSP specific policy and requirements. The following are general
guidelines recommended by the CMSAAC for the functions to be performed by the CMSP Infrastructure:

13
14
15

Authentication of interactions with the Mobile Device which is dependent upon the capabilities of the
delivery technology and CMSP policy. This function may not be part of CMAS but a capability of the
underlying delivery technology.

16
17

Distribute the received CMAS alert message to the determined set of cell sites/paging transceivers for
transmission to the mobile devices within the range of cell sites/pager transceivers.

18
19
20

For each specified cell site/pager transceiver, transmit the CMAS alert message using the delivery
technology or delivery technologies supported by the CMSP for that specific cell site/paging
transceiver.

2.3.4

Reference Points D & E

22
23

Reference Point D is the interface between the CMSP Gateway and the CMSP Infrastructure. Reference
Point E is the interface between the CMSP Infrastructure and the mobile device including the air interface.

24
25
26
27
28

Reference Points D and E are defined and controlled by the Commercial Mobile Service Providers. The
CMSAAC recommendations in this document define what type of information needs to be conveyed across
Reference Point E to support CMAS alerts on mobile devices. The CMSAAC recommends that the
definition of the Reference Point D and E protocols be performed by the commercial mobile service
providers in conjunction with the CMSP infrastructure network vendors and the mobile device vendors.

2.3.5

Mobile Device

30
31
32
33
34

Mobile device functionality is generally dependent on delivery technology, the capabilities of the delivery
technology, and mobile vendor/CMSP specific policy and requirements. CMAS should allow for mobile
device vendor flexibility in the design of CMA user interactions, and allow for innovation by the mobile
device vendors and CMSPs, especially as mobile device technology advances. The following are general
guidelines recommended by the CMSAAC for the functions to be performed by the Mobile Device:

35
36

Authentication of interactions with the CMSP infrastructure. The authentication will not be part of the
CMAS alert and is delivery technology dependent.

37
38

Determination of delivery technology or delivery technologies being supported by the Commercial
Mobile Service Provider in the subscriber’s current visited network.

39
40

Monitor associated channel or channels according to the requirements of the delivery technology or
delivery technologies for CMAS alerts.

Maintain configuration of CMAS alert options including the following:

Subscriber’s choice of CMAS alert opt-out selections.

Subscriber’s preferred language for CMAS alerts if applicable to the delivery technology.

44
45

Default language is English if CMAS alert is not being transmitted in subscriber’s preferred
language.
15

Commercial Mobile Alert Service Architecture and Requirements

1
2

Extraction of the CMAS alert content in the subscriber’s preferred language or in the default language
of English, if the CMAS alert is not being transmitted in the subscriber’s preferred language.

3
4

Presentation of received CMAS alert content to the mobile device user in accordance with the
capabilities of the mobile device, if the CMAS alert complies with the subscriber’s opt-out selections.

Presidential level CMAS alerts are always presented.

6
7

Presentation of a CMAS alert will activate associated visual, audio, and mechanical (e.g.,
vibration) indicators per subscriber options configured on the mobile device.

Detection and suppression of presentation of duplicate CMAS alerts.

9
10

Suppression of CMAS alert visual, audio and mechanical (e.g., vibration) indicators upon subscriber’s
action on the mobile device user interface (e.g., key stroke, touch screen).

Commercial Mobile Alert Service Architecture and Requirements

1
2

3 Deployment Scenarios

3
4
5

The WARN Act specifies that a commercial mobile service operator who elects to transmit emergency
alerts can elect to transmit the CMAS alerts in whole or in part. 7 The CMSAAC recommends that the
definition of “in whole or in part” include the following:

•

All or a subset of the CMSP’s service area

•

All or a subset of current and future mobile devices supported by the CMSP network

For reasons detailed in Annex B – WARN Act Statutory Requirements, the date of election is likely not the
date of deployment. Therefore the CMSAAC recommends that the process for a CMSP to “file an election
with the Commission with respect to whether or not it intends to transmit emergency alerts” should include
the following information:

8
9
10
11
12

Potential date of initial deployment

Potential date when mobile device(s) with CMAS support are available for consumer purchase

Whether the deployment will be “in whole or in part”

15
16
17
18
19
20

It is important to understand the various scenarios that may be deployed in CMSP networks to support
CMAS for those CMSP that do elect to transmit the CMAS alerts in whole or part. In addition, these
scenarios need to be understood for the development of appropriate information a CMSP must provide to
the subscriber to educate them on the availability of CMAS alerts. This information also needed to educate
the sources of the CMAS alerts so there is not an unrealistic expectation as to the percentage of population
to which the alert message may be broadcast.

21
22
23

Note: the following diagrams shows variety of mobile devices (i.e. cellular mobile phones and pagers) as
illustrative examples; it is not the intention to suggest all mobile device technologies are supported by a
single operator or via a single CMSP network.

WARN Act, § 602(b)(1)(B).
17

Commercial Mobile Alert Service Architecture and Requirements

3.1

Scenarios for Single Technology Deployed

3.1.1

Scenario – CMAS in Entire Single Technology Operator
Network on All Devices

4
5
6

This scenario illustrates where the CMSP deploys a single delivery technology within the CMSP network
to support CMAS alerts, and all mobile devices on that network support the delivery technology and thus
the reception of the CMAS alerts.

7
8

Figure 3-1

CMAS in Entire Single Technology Network on All Devices

Commercial Mobile Alert Service Architecture and Requirements

Scenario – CMAS in Entire Single Technology Operator
Network on a Subset of Devices

3
4
5

This scenario illustrates where the CMSP deploys a single delivery technology within the CMSP network
to support CMAS alerts, and only a subset of mobile devices on that CMSP network support the delivery
technology and thus the reception of the CMAS alerts.

3.1.2

6
7
8

Figure 3-2

CMAS in Entire Network on Sub-set of Devices

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6

3.1.3

Scenario – CMAS in Subset of Single Technology
Operator’s Network on All Devices

This scenario illustrates where the CMSP deploys a single delivery technology in a subset of the CMSP
network to support CMAS alerts, and all mobile devices on that CMSP network support the delivery
technology and thus the reception of the CMAS alerts while in the portion of the CMSP network where the
delivery technology is deployed.

7
8

Figure 3-3

CMAS in Subset of Single Technology Operator’s Network on All Devices

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6

3.1.4

Scenario – CMAS in Subset of Single Technology
Operator’s Network on Subset of Devices

This scenario illustrates where the CMSP deploys a single delivery technology in a subset of the CMSP
network to support CMAS, and only a subset of mobile devices on the CMSP network support the delivery
technology and thus the reception of the CMAS alerts while in the portion of the CMSP network where the
delivery technology is deployed.

Alerting Interface
Domain

Operator
Domain

Alerting Gateway
Domain

7
8

Figure 3-4

CMAS in Subset of Single Technology Operator’s Network on Subset of Devices

Commercial Mobile Alert Service Architecture and Requirements

3.2

Scenarios for Multiple Technologies Deployed

3.2.1

Scenario – CMAS in Entire Multiple Technology
Operator Network on All Devices

3
4
5
6

This scenario illustrates where the CMSP deploys a multiple delivery technologies within the CMSP
network to support CMAS alerts, and all mobile devices on that CMSP network support all delivery
technologies and thus the reception of the CMAS alerts.

7
8

Figure 3-5

CMAS in Entire Multiple Technology Operator Network on All Devices

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6

3.2.2

Scenario – CMAS in Entire Multiple Technology
Operator Network on Subset of Devices

This scenario illustrates where the CMSP deploys multiple delivery technologies within the CMSP network
to support CMAS alerts, and only a subset of mobile devices on the CMSP network supports one or both
delivery technologies and thus the reception of the CMAS alerts. Some mobile devices may not support
either deliver technology.

7
8

Figure 3-6

CMAS in Entire Multiple Technology Operator Network on Subset of Devices

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7

3.2.3

Scenario – CMAS in Subset of Multiple Technology
Operator Network on Subset of Devices

This scenario illustrates where the CMSP deploys multiple delivery technologies on a subset of the CMSP
network to support CMAS alerts, and only a subset of mobile devices on the CMSP network support one or
both delivery technologies and thus the reception of the CMAS alerts. Some mobile devices may not
support either delivery technology. This is a realistic picture of the deployment of CMAS, especially in a
nationwide scenario.

8
9
10

Figure 3-7

CMAS in Subset of Multiple Technology Operator Network on Subset of Devices

Commercial Mobile Alert Service Architecture and Requirements

3.3

1
2
3

Scenario for Operator Does Not Elect to Transmit CMAS
Alerts

This option illustrates where the CMSP does not elect to transmit CMAS alerts.

4
5
6

Figure 3-8

Operator Does Not Elect to Transmit CMAS Alerts

3.4

8
9
10
11
12
13
14

The CMSAAC, in collaboration with the Cellular Telephone and Internet Association (CTIA) and its membership
developed the proposed text to be used by commercial mobile service providers to notify their subscribers 1) when
they intend to transmit emergency alerts “in part” or 2) when they do not intend to transmit emergency alerts. The
WARN Act appears not to require specific text be developed for service providers who elect to transmit emergency
alerts throughout its entire coverage area. Therefore no text was developed for that case.

3.4.1

15
16
17
18
19
20

Notification Procedures

The CMSAAC recommends that carriers retain the discretion to determine how to provide specific information
regarding (1) whether or not they offer wireless emergency alerts, and (2) which devices are or are not capable of
receiving wireless emergency alerts, as well as how to tailor additional notice, if necessary, for devices offered at
other points of sale, i.e., retail outlets, mobile virtual network operators (MVNOs) and third party vendors.

3.4.2

21
22
23
24
25
26
27
28

Subscriber Notification Recommendations

Notification Text Recommendations

The CMSAAC submits the following recommended notice text, consistent with the requirements of the WARN Act.
I.

NOTICE BY CARRIER WHO INTENDS TO TRANSMIT EMERGENCY ALERTS “IN PART.”
NOTICE REGARDING TRANSMISSION OF
WIRELESS EMERGENCY ALERTS (Commercial Mobile Alert Service)
25

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

[[WIRELESS PROVIDER]] has chosen to offer wireless emergency alerts within portions of its service
area, as defined by the terms and conditions of its service agreement, on wireless emergency alert capable
devices. There is no additional charge for these wireless emergency alerts.
Wireless emergency alerts may not be available on all devices or in the entire service area, or if a
subscriber is outside of the [WIRELESS PROVIDER’s] service area. For details on the availability of this
service and wireless emergency alert capable devices, please ask a sales representative, or go to [[INSERT
WEBSITE URL]].
Notice required by FCC Rule XXXX (Commercial Mobile Alert Service).

II. NOTICE BY CARRIER WHO, “IN WHOLE,” DOES NOT INTEND TO TRANSMIT EMERGENCY
ALERTS

NOTICE TO NEW AND EXISTING SUBSCRIBERS REGARDING TRANSMISSION OF WIRELESS
EMERGENCY ALERTS (Commercial Mobile Alert Service)
[[WIRELESS PROVIDER]] presently does not transmit wireless emergency alerts.
Notice required by FCC Rule XXXX (Commercial Mobile Alert Service).

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6

4 CMAS Alert Scenarios
This section provides descriptions recommended by the CMSAAC for many common scenarios which are
related to the support of CMAS Alert messages. These scenarios are a representative sample and do not
include all possible sequences and/or events. Specifically this section will include descriptions of the
following scenarios:

7
8

•

Nominal CMAS alert scenarios for text based CMAS alert, as well as future capabilities of
streaming audio, streaming video, and downloaded multimedia CMAS alerts

•

CMAS alert cancellation scenario

10
11

•

CMAS alert update scenarios for text based CMAS alert, as well as future capabilities of
streaming audio, streaming video, and downloaded multimedia CMAS alerts

•

CMAS alert expiration scenario

13
14

•

Duplicate CMAS alerts scenarios for both duplicate CMAS alerts on the same broadcast
technology and duplicate CMAS alerts from different broadcast technologies

•

Multiple different active CMAS alerts scenarios

•

Multiple different CMAS alerts

4.1

Nominal CMAS Alert Scenarios

4.1.1

Scenario for Nominal Text CMAS Alert

18
19
20
21

An event has occurred and the appropriate government entities have decided to issue a text based CMA to
warn the CMSP subscribers within the indicated alerting area.

22
23

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

4.1.1.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

27
28

Mobile device is in state that allows for the detection and reception of the CMA (e.g., not busy, not on
a voice call).

No previous Commercial Mobile Alert Message (CMAM) is being broadcast by the CMSP.

There is no active CMAM on mobile device.

CMSP subscriber is within the alerting area for the CMA.

4.1.1.2

Normal Flow

33
34

The normal flow for the text based CMA is described in the following steps and in the associated flow
diagram which follows:

35
36

The appropriate government entity creates the alert message in CAP format which is sent to the
government alerting network over Reference Point A.

The government alerting network validates and authenticates the received alert request.

38
39

If the alert fails validation or authentication, an error response is returned to the originating
government entity and the alert is not sent to the CMSP. End of scenario.
27

Commercial Mobile Alert Service Architecture and Requirements

1
2

The government alerting network converts the received alert message into the text profile based CMAS
format supported by the CMSP.
a.

If the alert fails conversion, the alert is not sent to the CMSP. End of scenario.

The text profile based CMAM is sent to the CMSP over Reference Point C.

The CMSP validates the received CMAM.

6
7

If the CMAM fails validation, an error response is returned to the government alerting
network and the CMAM is not broadcast by the CMSP. End of scenario.

8
9

The CMSP sends an acknowledgement to the government alerting network that a valid CMAM has
been received.

10
11

The CMSP performs geo-targeting to translate the indicated alert area into the associated set of cell
sites / paging transceivers for the broadcast of the CMA.

12
13

If the CMSP does not support CMAS in the indicated alert area, the CMAM is not broadcast
by the CMSP. End of scenario.

14
15

If the CMSP does not have any cell site / paging transceiver coverage within the indicated
alert area, the CMAM is not broadcast by the CMSP. End of scenario.

16
17

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
CMSP which support the CMAS service are used for the broadcast of the CMAM.

18
19

20
21
22
23
24
25
26
27
28
29
30
31
32
33

The CMSP broadcasts the CMAM to the set of cell sites / paging transceivers identified by the geotargeting processing in the previous step.
a.

The CMAM is broadcast via the CMSP selected technology.

The mobile device monitors for the broadcast of the CMAM via the CMSP selected technology.
a.

If the CMAM is not a Presidential alert and if the end user opt-out selections for CMAS alerts
indicate that this type of CMAM is not to be presented, the CMAM is discarded or ignored.
End of scenario.

10. The CMAM is received and presented to the end user including the activation of the CMAS audio
attention signal and/or the activation of the special emergency alert vibration cadence (if mobile device
has vibration capabilities) for a short duration as defined by CMSP policies and by the capabilities of
the mobile device, and display of the CMAM message text on the visual display of the mobile device.
a.

Activation of the CMAS audio attention signal and/or special vibration cadence complies with
the end user mobile device configuration as defined in Section 7.2, below.

11. The behavior of the mobile device beyond this point is outside the scope of the WARN Act and,
therefore, is not subject to recommendations by the CMSAAC. The functionality of the mobile device
is CMSP and mobile device specific.

34
35

Commercial Mobile Alert Service Architecture and Requirements

Reference
Point A’

Government
Alerting
Network

Reference
Point C

CMSP
Network

Reference
Point E

Mobile Device

End User

1. Alert created

2. Alert validated

3. Alert converted

4. CMAM sent to CMSP

5. CMAM validated

6. CMAM acknowledged

7. Geo-targeting performed

8. Broadcast CMAM

9. Monitor for CMAM

10. Alert received, alarm
issued & alert text
displayed

11. Behavior of Mobile Device Beyond
This Point Outside Scope of WARN Act

1
2

Figure 4-1

Flow for Scenario for Nominal Text CMAS Alert

3
4
5
6

4.1.2

Scenario for Nominal Streaming Audio or Streaming
Video CMAS Alert

Streaming audio or streaming video CMAS alerts are a future capability.

Commercial Mobile Alert Service Architecture and Requirements

4.1.3

2
3

Scenario for Nominal Downloaded Multimedia CMAS
Alert

Downloaded multimedia CMAS alerts are a future capability.

4
5

4.2

CMAS Alert Cancellation Scenario

6
7
8
9

The event that caused the issuance of the CMA has changed and the appropriate government entities have
decided that the event is no longer an imminent threat to life or property. Consequently the appropriate
government entities have decided to issue a cancellation of the CMA.

10
11

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

12
13
14

If the received CMAM cancellation is not valid and if, as a part of its implementation, the CMSP has
enabled message retransmission, the CMSP may continue to send the original alert until expiry or until a
valid CMAM cancellation is received.

4.2.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

18
19

Mobile device is in state that allows for the detection and reception of the CMA (e.g., not busy, not on
a voice call).

20
21
22

A previous non-expired Commercial Mobile Alert Message (CMAM) has been broadcast by the
CMSP and has been received by the mobile device (i.e., there is an active CMAM on the mobile
device).

CMSP subscriber is within the alerting area of the active CMA.

4.2.2

Normal Flow

25
26

The normal flow for the cancelled CMA is described in the following steps and in the associated flow
diagram which follows:

27
28

The appropriate government entity creates the alert cancellation message in CAP format which is sent
to the government alerting network over Reference Point A.

The government alerting network validates and authenticates the received alert cancellation request.

30
31
32
33

If the alert fails validation or authentication, an error response is returned to the originating
government entity and the alert cancellation is not sent to the CMSP. End of scenario.

3. The government alerting network converts the received alert message into the text profile based CMAS
format support by the CMSP

34
35
36
37
38
39

The Alert Gateway ensures that the urgency, severity, certainty match the values of those fields in
the original message. As a consequence, a cancelled CMAM passed to the CMSP Gateway has
the same urgency, severity, certainty, and message category as the original CMA alert in order to
ensure the opt-out filter on the handset is the same for both messages. Therefore if the original
CMAM was ignored based on opt-out criteria, then the CMAM cancellation should also be
ignored.

If the alert fails conversion, the alert cancellation is not sent to the CMSP. End of scenario.

The CMAM cancellation is sent to the CMSP over Reference Point C.

The CMSP validates the received CMAM cancellation.
30

Commercial Mobile Alert Service Architecture and Requirements

1
2

If the CMAM cancellation fails validation, an error response is returned to the government alerting
network and the CMAM cancellation is not broadcast by the CMSP. End of scenario.

3
4

The CMSP sends an acknowledgement to the government alerting network that a valid CMAM
cancellation has been received.

5
6

The CMSP discontinues the broadcasts the associated CMAM including the text component and any
associated audio, video, or multimedia components.

7
8

The CMSP performs geo-targeting to translate the indicated alert area into the associated set of cell
sites / paging transceivers for the broadcast of the CMA.

9
10

If the CMSP does not support CMAS in the indicated alert area, the CMAM is not broadcast
by the CMSP. End of scenario.

11
12

If the CMSP does not have any cell site / paging transceiver coverage within the indicated
alert area, the CMAM is not broadcast by the CMSP. End of scenario.

13
14

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
CMSP which support the CMAS service are used for the broadcast of the CMAM.

15
16

The CMSP broadcasts the CMAM cancellation to the same set of cell sites / paging transceivers
identified by the geo-targeting processing in the previous step.

17
18

10. The mobile device monitors for the broadcast of the CMAM cancellation via the CMSP selected
technology and receives the CMAM cancellation.

19
20
21
22
23
24
25
26
27
28
29
30
31

If the CMAM cancellation is not a Presidential alert and if the end user opt-out selections for
CMAS alerts indicate that this type of CMAM is not to be presented, the CMAM cancellation
is discarded or ignored. End of scenario.

11. The CMAM cancellation is received and the CMAM cancellation is presented to the end user
including the activation of the CMAS audio attention signal and/or the activation of the special
emergency alert vibration cadence (if mobile device has vibration capabilities) for a short duration as
defined by CMSP policies and the capabilities of the mobile device, and the display of the CMAM
cancellation message text on the visual display of the mobile device.
a.

Activation of the CMAS audio attention signal and/or special vibration cadence will comply with
the end user mobile device configuration as defined in Section 7.2 below.

12. The behavior of the mobile device beyond this point is outside the scope of the WARN Act and,
therefore, is not subject to recommendations by the CMSAAC. The functionality of the mobile device
is CMSP and mobile device specific.

Commercial Mobile Alert Service Architecture and Requirements

Reference
Point A’

Government
Alerting
Network

Reference
Point C

Reference
Point E

CMSP
Network

Mobile Device

End User

Previous CMAM With Optional Audio, Video, and/or Multimedia Components Being Broadcast
1. Alert cancellation
created

2. Alert cancellation
validated

3. Alert cancellation
converted

4. CMAM cancellation
sent to CMSP

5. CMAM cancellation
validated
6. CMAM cancellation
acknowledged

7. Discontinue broadcast
of previous associated
CMAM

8. Geo-targeting performed
9. Broadcast CMAM
cancellation message

10. Monitor for CMAM
cancellation

11. Alert cancellation
received, alarm issued &
alert text displayed

12. Behavior of Mobile Device Beyond
This Point Outside Scope of WARN Act

1
2

Figure 4-2

Flow for CMAS Alert Cancellation Scenario

3
4
32

Commercial Mobile Alert Service Architecture and Requirements

4.3

CMAS Alert Update Scenarios

4.3.1

Scenario for Update of Text CMAS Alert

2
3
4
5
6

The appropriate government entities have decided to issue an update to a previously issued text based CMA
to warn the CMSP subscribers within the indicated alerting area about changes associated with the event
that caused the issuance of the previous CMA.

7
8

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

9
10
11
12

4.3.1.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

15
16

Mobile device is in state that allows for the detection and reception of the CMA (e.g., not busy, not on
a voice call).

The CMSP may be broadcasting a previous CMA which is associated with the updated CMA.

A CMAM may be active on mobile device.

CMSP subscriber is within the alerting area of the updated CMA.

4.3.1.2

Normal Flow

21
22

The normal flow for the update of text based CMAM is described in the following steps and in the
associated flow diagram which follows:

23
24

The appropriate government entity creates the updated alert message in CAP format which is sent to
the government alerting network over Reference Point A.

The government alerting network validates and authenticates the received updated alert request.

26
27
28
29

a.
3.

If the alert fails validation or authentication, or conversion, an error response is returned to the
originating government entity and the alert is not sent to the CMSP. End of scenario.

The government alerting network converts the received alert message into the text profile based CMAS
format supported by the CMSP.

30
31
32
33
34

The Alert Gateway ensures that the urgency, severity, certainty match the values of those fields in
the original message. As a consequence, an updated CMAM passed to the CMSP Gateway has
the same urgency, severity, certainty, and message category as the original CMA alert in order to
ensure the opt-out filter on the handset is the same for both messages. Therefore if the original
CMAM was ignored based on opt-out criteria, then the updated CMAM should also be ignored.

If the alert fails conversion, the alert is not sent to the CMSP. End of scenario.

The updated text based CMAM is sent to the CMSP over Reference Point C.

The CMSP validates the received updated CMAM.

38
39

If the updated CMAM fails validation, an error response is returned to the government alerting
network and the updated CMAM is not broadcast by the CMSP. End of scenario.

40
41

The CMSP sends an acknowledgement to the government alerting network that a valid updated
CMAM has been received.

The CMSP discontinues any broadcasts of the previously issued CMAM.
33

Commercial Mobile Alert Service Architecture and Requirements

1
2

The CMSP performs geo-targeting to translate the indicated alert area into the associated set of cell
sites / paging transceivers for the broadcast of the updated CMAM.

3
4

If the CMSP does not support CMAS in the indicated alert area, the updated CMAM is not
broadcast by the CMSP. End of scenario.

5
6

If the CMSP does not have any cell site / paging transceiver coverage within the indicated alert
area, the updated CMAM is not broadcast by the CMSP. End of scenario.

7
8

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
CMSP which support the CMAS service are used for the broadcast of the updated CMAM.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

The CMSP broadcasts the updated CMAM to the set of cell sites / paging transceivers identified by the
geo-targeting processing in the previous step.
a.

The updated CMAM is broadcast via the CMSP selected technology.

10. The mobile device monitors for the broadcast of the updated CMAM via the CMSP selected
technology.
a.

If the updated CMAM is not a Presidential alert and if the end user opt-out selections for CMAS
alerts indicate that this type of CMAS alert is not to be presented, the updated CMAM is discarded
or ignored. End of scenario.

11. The updated CMAM is received and presented to the end user including the activation of the CMAS
audio attention signal and/or the activation of the special emergency alert vibration cadence (if mobile
device has vibration capabilities) for a short duration as defined by CMSP policies and the capabilities
of the mobile device, and the display of the updated CMAM message text on the visual display of the
mobile device.
a.

Activation of the CMAS audio attention signal and/or special vibration cadence complies with the
end user mobile device configuration as defined in Section 7.2 below.

Commercial Mobile Alert Service Architecture and Requirements

Reference
Point A’

Government
Alerting
Network

Reference
Point C

Reference
Point E

CMSP
Network

Mobile Device

End User

Previous Associated Text CMAM Being Broadcast
1. Updated alert
created

2. Updated alert
validated

3. Updated alert
converted

4. Updated CMAM sent
to CMSP

5. Updated CMAM
validated
6. Updated CMAM
acknowledged

7. Discontinue broadcast
of previous associated
CMAM

8. Geo-targeting performed

9. Broadcast updated
CMAM

10. Monitor for updated
CMAM

11. Updated alert
received, alarm issued &
alert text displayed

12. Behavior of Mobile Device Beyond
This Point Outside Scope of WARN Act

1
2

Figure 4-3

Flow for Scenario for Update of Text CMAS Alert

3
4
35

Commercial Mobile Alert Service Architecture and Requirements

4.3.2

2
3

Scenario for Update of Streaming Audio or Streaming
Video CMAS Alert

Streaming audio or streaming video CMAS alerts are a future capability.

4
5

4.3.3

6
7

Scenario for Update of Downloaded Multimedia CMAS
Alert

Downloaded multimedia CMAS alerts are a future capability.

8
9
10
11
12

4.4

CMAS Alert Expiration Scenario

The previously issued Commercial Mobile Alert Message (CMAM) alert has reached its expiration time
without having been updated or cancelled. This scenario describes the functionality when the expiration
time has been detected.

13
14
15
16

4.4.1
1.

Pre-Conditions

The associated non-expired non-cancelled CMAM has been or is currently being broadcast by the
CMSP.

17
18

4.4.2

Normal Flow

19
20

The normal flow for the CMAS alert expiration is described in the following steps and in the associated
flow diagram which follows:

The expiration time of a previously issued CMAM has been determined by the CMSP.

22
23

Any active broadcasts of text component of the previously issued CMAM are discontinued by the
CMSP.

24
25

All active broadcasts of any associated audio, video, or multimedia components of the previously issue
CMAM are discontinued by the CMSP.

Commercial Mobile Alert Service Architecture and Requirements

1
2

Figure 4-4

Flow for CMAS Alert Expiration Scenario

3
4

4.5

Duplicate CMAS Alerts Scenarios

4.5.1

Scenario for Duplicate CMAS Alerts on Same Broadcast
Technology

5
6
7
8
9

A CMAM is being retransmitted by the CMSP network. The mobile device detects and ignores the
duplicate CMAM.

10
11

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

12
13

4.5.1.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

16
17

Mobile device is in state that allows for the detection and reception of CMAM (e.g., not busy, not on a
voice call).

A previous copy of the CMAM has been broadcast by the CMSP.

The previous copy of the CMAM is contained on mobile device.

CMSP subscriber is still within the alerting area for the CMA.

21
22
23

4.5.1.2

Normal Flow

The flow for duplicate CMAM on the same broadcast technology is described in the following steps and in
the associated flow diagram which follows:
37

Commercial Mobile Alert Service Architecture and Requirements

The CMSP network retransmits a previously broadcast CMAM.

2
3

The CMAM being retransmitted contains the same message identifier as the previously broadcast
version.

4
5

The retransmission could be performed by the CMSP selected delivery technology depending on
the capabilities of the delivery technology.

The mobile device monitors for the broadcast of the CMAM via the CMSP selected technology.

7
8

The mobile device detects the received CMAM as a duplicate CMAM based upon message identifier
and other message attributes. The duplicate CMAM is ignored and discarded by the mobile station.

10
11

Figure 4-5

Flow for Scenario for Duplicate CMAS Alerts on Same Broadcast Technology

Scenario for Duplicate CMAS Alerts on Different
Broadcast Technologies

15
16
17
18

An event has occurred and the appropriate government entities have decided to issue a text based CMA to
warn the CMSP subscribers within the indicated alerting area. The CMSP network supports more than one
broadcast technology in the indicated alerting area and the CMSP elects to broadcast the CMA on more
than one technology in the indicated alerting area.

19
20

Support of multiple broadcast technologies by the CMSP network may be result of the deployment and
implementation of newer broadcast technologies.

21
22

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

4.5.2

23
24

4.5.2.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

Commercial Mobile Alert Service Architecture and Requirements

1
2

Mobile device is in state that allows for the detection and reception of the CMA (e.g., not busy, not on
a voice call).

No previous CMAM is being broadcast by the CMSP.

There is no active CMAM on mobile device.

CMSP subscriber is still within the alerting area for the CMA.

The mobile device is capable of receiving the CMAM from more than one broadcast technology.

7
8

4.5.2.2

Normal Flow

9
10

The flow for duplicate text profile based CMAS alerts on the different broadcast technologies is described
in the following steps and in the associated flow diagram which follows:

11
12

The appropriate government entity creates the alert message in CAP format which is sent to the
government alerting network over Reference Point A.

The government alerting network validates and authenticates the received alert request.

14
15
16
17

a.
3.

If the alert fails validation or authentication, an error response is returned to the originating
government entity and the alert is not sent to the CMSP. End of scenario.

The government alerting network converts the received alert message into the text profile based CMAS
format supported by the CMSP.
a.

If the alert fails conversion, the alert is not sent to the CMSP. End of scenario.

The text profile based CMAM is sent to the CMSP over Reference Point C.

The CMSP validates the received CMAM.

21
22

If the CMAM fails validation, an error response is returned to the government alerting
network and the CMAM is not broadcast by the CMSP. End of scenario.

23
24

The CMSP sends an acknowledgement to the government alerting network that a valid CMAM has
been received.

25
26

The CMSP performs geo-targeting to translate the indicated alert area into the associated set of cell
sites / paging transceivers for the first broadcast technology used for the broadcast of the CMAM.

27
28

If the CMSP does not support CMAS in the indicated alert area, the CMAM is not broadcast
by the CMSP. End of scenario.

29
30
31
32

If the CMSP does not have any cell site / paging transceiver coverage for the first broadcast
technology within the indicated alert area, the CMAM is not broadcast by the CMSP using the
first broadcast technology. The CMAM will be processed as described in Section 4.1.1
above. End of scenario.

33
34
35

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
first broadcast technology of the CMSP which support the CMAS service are used for the
broadcast of the CMAM.

36
37

38
39
40
41
42
43
44

The CMSP broadcasts the CMAM using the first broadcast technology to the set of cell sites / paging
transceivers identified by the geo-targeting processing in the previous step.
a.

The CMAM is broadcast via the first CMSP selected technology.

The CMSP performs geo-targeting to translate the indicated alert area into the associated set of cell
sites / paging transceivers for the second broadcast technology used for the broadcast of the CMAM.
a.

If the CMSP does not have any cell site / paging transceiver coverage for the second
broadcast technology within the indicated alert area, the CMAM is not broadcast by the
CMSP using the second broadcast technology. The CMAM is processed as described in
Section 4.1.1 above. End of scenario.
39

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
second broadcast technology of the CMSP which support the CMAS service are used for the
broadcast of the CMAM.

10. The CMSP broadcasts the CMAM using the second broadcast technology to the set of cell sites /
paging transceivers identified by the geo-targeting processing in the previous step.
a.

The CMAM is broadcast via the second CMSP selected technology.

11. The CMAM is received from both the first and second broadcast technologies.
12. Based upon mobile device capabilities and configurations, only one of the received CMAM will be
presented to the end user. The mobile device should only perform one activation of the CMAS audio
attention signal and/or the activation of the special emergency alert vibration cadence (if mobile device
has vibration capabilities).
a.

If the CMAM is not a Presidential alert and if the end user opt-out selections for CMAS alerts
indicate that this type of CMAS alert is not to be presented, the CMAM is discarded or
ignored. End of scenario.

13. The behavior of the mobile device beyond this point is outside the scope of the WARN Act and,
therefore, is not subject to recommendations by the CMSAAC. The functionality of the mobile device
is CMSP and mobile device specific.

Commercial Mobile Alert Service Architecture and Requirements

Reference
Point A’

Government
Alerting
Network

Reference
Point C

CMSP
Network

Reference
Point E

Mobile Device

End User

1. Alert created

2. Alert validated

3. Alert converted

4. CMAM sent to CMSP

5. CMAM validated

6. CMAM acknowledged

7. Geo-targeting
performed for 1st
broadcast technology
8. Broadcast CMAM on
1st broadcast technology

9. Geo-targeting
performed for 2nd
broadcast technology
10. Broadcast CMAM on
2nd broadcast technology

11. CMAM received on
both broadcast
technologies
12. Only one alarm
issued & only one alert
text displayed

13. Behavior of Mobile Device Beyond
This Point Outside Scope of WARN Act

1
2

Figure 4-6

Flow for Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies

Commercial Mobile Alert Service Architecture and Requirements

4.6

Multiple Different Active CMAS Alerts Scenario

2
3
4
5
6

An event has occurred and the appropriate government entities have decided to issue a text based CMA to
warn the CMSP subscribers within the indicated alerting area. During the broadcast period of the 1st alert
message, a second event has occurred for the same alerting area and the appropriate government entities
have decided to issue a second text based CMA to warn the CMSP subscribers within the indicated alerting
area.

7
8

The CMSP processes CMAM received from the Alert Gateway on a first come first served basis. There is
no prioritization of processing or delivery of CMAM within the CMSP network.

9
10

This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting
subscribers into the service area of the CMSP network which will be broadcasting the CMA.

11
12

4.6.1

Pre-Conditions

Mobile device is authorized and authenticated for service on CMSP network.

Mobile device is receiving adequate radio signal strength from the CMSP.

15
16

Mobile device is in state that allows for the detection and reception of CMA (e.g., not busy, not on a
voice call).

No previous CMAM is being broadcast by the CMSP.

There is no CMAM on mobile device.

CMSP subscriber is within the alerting area for the CMA.

Both CMA are to be issued for the same alerting area.

4.6.2

Normal Flow

22
23

The flow for multiple different CMAS alerts within the same alerting area is described in the following
steps and in the associated flow diagram which follows:

24
25

The appropriate government entity creates the 1st alert message in CAP format which is sent to the
government alerting network over Reference Point A.

The government alerting network validates and authenticates the 1st received alert request.

27
28
29
30

a.
3.

If the 1st alert fails validation or authentication, an error response is returned to the originating
government entity and the alert is not sent to the CMSP. End of scenario.

The government alerting network converts the 1st received alert message into the text profile based
CMAS format supported by the CMSP.
a.

If the alert fails conversion, the alert is not sent to the CMSP. End of scenario.

The 1st text profile based CMAM is sent to the CMSP over Reference Point C.

The CMSP validates the 1st received CMAM.

34
35

If the 1st CMAM fails validation, an error response is returned to the government alerting network
and the CMAM is not broadcast by the CMSP. End of scenario.

36
37

The CMSP sends an acknowledgement to the government alerting network that the 1st received
CMAM is valid.

38
39

The CMSP performs geo-targeting for the 1st CMAS alert to translate the indicated alert area into the
associated set of cell sites / paging transceivers for the broadcast of the 1st CMAM.

40
41

If the CMSP does not support CMAS in the indicated alert area, the 1st CMAM is not broadcast by
the CMSP. End of scenario.

Commercial Mobile Alert Service Architecture and Requirements

1
2

If the CMSP does not have any cell site / paging transceiver coverage within the indicated alert
area, the 1st CMAM is not broadcast by the CMSP. End of scenario.

3
4

If the entire nation is indicated as the alert area then all cell sites / paging transceivers of the
CMSP which support the CMAS service are used for the broadcast of the 1st CMA.

5
6

7
8
9
10
11
12

The CMSP broadcasts the 1st CMAM to the set of cell sites / paging transceivers identified by the geotargeting processing in the previous step.

The 1st CMAM is broadcast via the CMSP selected technology.

The 1st CMAM is received and presented to the end user including the activation of the CMAS audio
attention signal and/or the activation of the special emergency alert vibration cadence (if mobile device
has vibration capabilities) for a short duration as defined by CMSP policies and by the capabilities of
the mobile device, and display of the 1st CMAM message text on the visual display of the mobile
device.

13
14

If the 1st CMAM is not a Presidential alert and if the end user opt-out selections for CMAS alerts
indicate that this type of CMAS alert is not to be presented, the CMAM is discarded or ignored.

15
16

Activation of the CMAS audio attention signal and/or special vibration cadence complies with the
end user mobile device configuration as defined in Section 7.2 below.

17
18
19

10. An appropriate government entity creates a 2nd alert message in CAP format for the same alerting area
as the 1st alert message. The 2nd alert message is sent to the government alerting network over
Reference Point A.

11. The government alerting network validates and authenticates the 2nd received alert request.

21
22
23
24
25

If the 2nd alert fails validation or authentication, an error response is returned to the originating
government entity and the alert is not sent to the CMSP. End of scenario.

12. The government alerting network converts the 2nd received alert message into the text profile based
CMAS format supported by the CMSP.
a.

If the alert fails conversion, the alert is not sent to the CMSP. End of scenario.

13. The 2nd text profile based CMAM is sent to the CMSP over Reference Point C.

14. The CMSP validates the 2nd received CMAM.

28
29

If the 2nd CMAM fails validation, an error response is returned to the government alerting network
and the CMAM is not broadcast by the CMSP. End of scenario.

30
31

15. The CMSP sends an acknowledgement to the government alerting network that the 2nd received
CMAM is valid.

32
33

16. The CMSP performs geo-targeting for the 2nd CMAM to translate the indicated alert area into the
associated set of cell sites / paging transceivers for the broadcast of the 2nd CMAM.

34
35
36
37
38

For this scenario, since the indicated alert area of the 1st and 2nd CMAM are the same, the results
of the geo-targeting for both the 1st and 2nd CMAM should return the same set of cell sites / paging
transceivers.

17. The CMSP broadcasts the 2nd CMAM to the set of cell sites / paging transceivers identified by the geotargeting processing step.

The 2nd CMAM is broadcast via the CMSP selected technology.

40
41
42

The retransmission of the 1st CMAM and the initial transmission of the 2nd CMAM may be
simultaneously broadcast, or may be transmitted sequentially, depending on the delivery
technology

43
44
45
46
47

18. The 2nd CMAM is received and presented to the end user including the activation of the CMAS audio
attention signal and/or the activation of the special emergency alert vibration cadence (if mobile device
has vibration capabilities) for a short duration as defined by CMSP policies and by the capabilities of
the mobile device, and display of the 2nd CMAM message text on the visual display of the mobile
device.
43

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

If the 2nd CMAM is not a Presidential alert and if the end user opt-out selections for CMAS alerts
indicate that this type of CMAS alert is not to be presented, the 2nd CMAM is discarded or
ignored.

4
5

Activation of the CMAS audio attention signal and/or special vibration cadence complies with the
end user mobile device configuration as defined in Section 7.2 below.

The mobile device ignores the retransmission of the duplicate 1st CMAM.

7
8
9

The mobile device processing and presentation of multiple received CMAS alerts is outside the
scope of the WARN Act and, therefore, is not subject to recommendations by the CMSAAC. The
functionality of the mobile device is CMSP and mobile device specific

Commercial Mobile Alert Service Architecture and Requirements

Reference
Point A’

Government
Alerting
Network

Reference
Point C

CMSP
Network

Reference
Point E

Mobile Device

End User

1. 1st alert created

2. 1st alert validated

3. 1st alert converted

4. 1st CMAM sent to CMSP

5. 1st CMAM validated
6. 1st CMAM acknowledged

7. Geo-targeting
performed for 1st CMAM
8. Broadcast 1st CMAM
9. 1st CMAM
detected &
presented

10. 2nd alert created

11. 2nd alert validated

12. 2nd alert converted
13. 2nd CMAM sent to
CMSP

14. 2nd CMAM validated
15. 2nd CMAM
acknowledged

16. Geo-targeting
performed for 2nd CMAM
17. Broadcast 2nd CMAM
with retransmission of 1st
CMAM
18. 2nd CMAM
detected &
presented &
duplicate 1st CMAM
ignored

1
2

Figure 4-7

Flow for Scenario for Multiple Different Active CMAS Alerts Scenario

3
45

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8

5 General Requirements & Conclusions
The following section contains the CMSAAC’s general recommendations and conclusions for the CMAS.
Many of the conclusions and recommendations apply to initial deployments of the CMAS, for a text-based
service profile. Future technologies, such as streaming audio, streaming video, and multimedia, are
mentioned throughout this document; however, technology advances to support these future capabilities are
just beginning to be developed and introduced. As CMSPs gain experience with these technologies, the
applicability of those technologies to the CMAS will be better understood.

9
10
11
12
13
14
15
16
17
18

The CMSAAC recommends that this document be treated as a living document, with periodic updates to
account for experiences with initial CMAS deployments and experiences with new technologies and their
applicability to CMAS. An industry group consisting of government and industry stakeholders should be
created after the CMSAAC’s activity is complete to review and update this document on a periodic basis.
This review should occur no less frequently than biennially. It is expected that during research,
development, and deployment, this industry group may need to convene more frequently than biennially to
address research conclusions and any development or deployment issues.

5.1

Scope & Definition of CMAS Alerts

The CMSAAC recommends that there are three classes of Commercial Mobile Alerts:

Presidential-level

20
21

Imminent threat to life and property (defined as alerts where the CAP severity equals Extreme or
Severe, CAP urgency is Immediate or Expected, and CAP certainty is Observed or Likely).

Child Abduction Emergency or “AMBER Alert”

23
24

Because of the technical limitations in delivering emergency alerts on CMSP systems, the CMSAAC
recommends that only the 3 classes defined above will be transmitted as CMA messages.

25
26
27

The CMSAAC recommends that the CMSPs who elect to support CMAs are considered for this purpose
only to be agents of the federal, state, local, or tribal agencies that originate the alerts and are providing
CMAs on their behalf.

28
29
30
31
32
33

A CMSP that elects to transmit alerts under Section 602(b)(2) of the WARN Act may not impose a separate
or additional charge for such transmission or capability when the emergency alerts are transmitted in a
manner consistent with the technical standards, protocols, procedures, and other technical requirements
implemented by the Commission. For transmission or service beyond standards, protocols, procedures, and
other technical requirements implemented by the Commission, a Commercial Mobile Service licensee is
not bound by Section 602(b)(2)(C) of the WARN Act.

34
35
36
37

The Commercial Mobile Service licensee may utilize the technical standards, protocols, procedures, and
other technical requirements implemented by the Commission to support the WARN Act for other services
or purposes and are not bound by Section 602(b)(2)(C) of the WARN Act. The government portion, from
Reference Point A to Reference Point C, of the CMAS will not be made available for commercial use.

38
39
40
41

CMAS will be provided according to the technical standards, protocols, procedures, and other technical
requirements implemented by the Commission to support the WARN Act. A CMSP’s networks shall not
be bound to use any specific vendor, technology, software, implementation, client, device, or third party
agent, in order to meet the obligations under the WARN Act.

42
43
44

Technical standards, protocols, procedures, and other technical requirements implemented by the
Commission shall be standardized in industry fora which have a well-defined reasonable and nondiscriminatory intellectual property rights policy, allowing for multi-vendor implementations.

Commercial Mobile Alert Service Architecture and Requirements

1
2

It is anticipated that mobile devices that support CMAS may incur additional development and
manufacturing costs and these costs may be passed on to the subscriber.

3
4

A CMSP or any device deployed by a CMSP to support the transmission of CMAS alerts according to the
WARN Act shall not be required to identify location or location history of the mobile device.

5
6
7
8
9
10
11
12

The CMSAAC recommends that, prior to the adoption of rules as specified in the WARN Act Section 602
(b) (1), the Commission will require all participants in the CMSAAC and all participants in the public
comment process on this Commercial Mobile Alert Service Architecture and Requirements
document to provide written assurance to the Commission that, if and insofar as one or more licenses may
be required under any of their respective Intellectual Property Rights (IPR) 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.

5.2

14
15
16

This section contains the CMSAAC’s recommendations for general requirements and assumptions for
CMAS. More specific requirements and assumptions may be contained within the other sections of this
document.

General CMAS Requirements & Conclusions

17
18

Federal, state, tribal, and local level CMAS alert messages will be supported using the same CMAS
solution.

19
20
21

Point-to-point or unicast delivery technologies are not feasible or practical for the support of CMAS,
i.e. SMS point-to-point, MMS. Reasons for point-to-point technologies not being feasible or practical
are:

Point-to-point technologies can experience significant delivery delays.

23
24

Point-to-point technologies can result in network and radio interface congestion to the point of
blocking voice calls.

Point-to-point technologies lack security and can be easily spoofed.

26
27

Point-to-point technologies lack geo-targeting capabilities because it is targeted to phone numbers
instead of a specific alert area.

28
29

Point-to-point technologies lack emergency alert specific alert tones and thereby emergency alerts
can not be distinguished from normal SMS message traffic.

Point-to-point technologies lack support of roamers

31
32

For a CMSP that elects to transmit CMAS alerts, text is the minimum requirement for CMAS alert
messages. All CMAS alert messages delivered to the CMSP will contain at least a textual component.

33
34

No new CALEA lawful intercept access points will be created for CMAS alert broadcast delivery
technologies.

35
36
37
38

There is no interaction between CMAS alert message delivery and Number Portability. There is no
guarantee that the end user will receive the CMAS alert message during the time interval that the
user’s subscription is being ported between CMSPs. As part of Number Portability, there is no service
portability between CMSPs.

39
40

It is not a requirement to support CMAS on non-initialized mobile devices, including mobile devices
that are not authorized for service.

41
42
43
44

CMAS is intended for commercial mobile services (i.e, cellular phones and pagers) supported by
commercial mobile service licensees. Some devices are not designed to support CMAS (e.g.,
telematics, data only devices such as laptop data cards) and thus are outside the scope of the CMAS
architecture.

45
46
47

Broadcast technologies such as MediaFLO, DVB-H, and FM/RBDS receivers are not considered
as part of the CMAS. Service providers of these technologies do not hold commercial mobile
service licenses as they do not provide interconnect service, and are not licensed to transmit in the
47

Commercial Mobile Alert Service Architecture and Requirements

1
2

same channels as commercial mobile services. It is recognized that these technologies may
provide supplemental alert information for the CMAS.

5.3

Recommendations for Alert Initiation & Alert Initiators

5.3.1

CMAM Elements

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

The CMAMs are delivered across Reference Point C to the CMSP network at no cost to the CMSP.

A typical emergency alert message issued by the National Weather Service on weather radio might appear
as follows:
“The National Weather Service in Phoenix has issued a severe thunderstorm warning for northwest
Maricopa County effective until 5pm local time. Seek shelter now inside a sturdy structure and stay
indoors!”
(Note the above message contains over 200 characters and spaces and is not in the correct format for a
CMAM).
The CMSAAC recommends that CMAMs follow this same general format, within the text character
limitations of CMA as defined in the text profile in Section 6.2 below. Given the rapidly evolving nature of
wireless technology, the biennial review committee shall review whether the character limit profile, as
described in Section 6.2, may be increased.
The necessary elements of an effective CMAM and the order in which they should be presented in the
CMAM are:
1.

What’s Happening (Event Type or Event Category )

Area affected (in this area)

Recommended action (Response description)

Expiration time with time zone (Represented as a distinct time – e.g., until 09:30 AM EDT)

Sending Agency (agency type, i.e. police, fire, national weather service, etc.)

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

NOTE: The above format for a CMAM is recommended for initial deployments of CMAS and as
experience is gained by alert initiators and by CMSPs, we envision that the format will evolve to provide to
the most efficient and informative format for the CMAMs.

5.3.2

Generating CMAM from CAP Fields

For initial CMAS system deployments and until Alert Initiators are trained in the generation of CMAM, in
order to create consistent and accurate CMAMs, the CMSAAC recommends that the Alert Gateway
“construct” the CMAM using selected required and optional fields in the CAP message. The translated
CMAM will then be transmitted to the CMSP across the Reference Point C.
Allowing the Alert Gateway to create the CMAM using CAP fields creates consistent and accurate
messages and will enable enhancements to be made over time in the Alert Gateway and made available to
all CMA capable mobile devices in the field. For instance, if a new alert event is identified, a new event
code or category can be added to the CAP message, translated in the Alert Gateway and a new text string
can be sent to the mobile device through the CMSP Gateway.
However, generating CMAM using CAP fields may not provide flexibility to Alert Initiators to tailor the
CMAM content to a specific alert event. Even though CMAS is not intended to provide comprehensive
alert information, a CMAM with a “what is happening“ text indicating “security warning” may not be very
meaningful to the end user. The recent steam pipe explosion in New York City and the Virginia Tech
48

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

shootings are examples where an automatically generated CMAM would not have provided meaningful
information in the CMAM text.
The CMSAAC recommends the use of the sender identity used by the Alert Gateway in the Trust Model to
identify the sender. The Alert Gateway will then assign an agreed upon text phrase or abbreviation (e.g.,
VDOT, NWS, etc.) to be transmitted to the CMSP Gateway.
The CMSAAC makes the following recommendations regarding the use of the required category and
optional eventCode CAP fields. They are:
1.

Encourage the National Weather Service to continue its practice of using codes, such as SAME
codes, in the eventCode field to identify weather alerts.

When the eventCode field is populated with a value, that value will be used by the Alert Gateway
to determine what text phrase will be transmitted to the CMSP gateway (e.g., TOR will be
translated to Tornado Warning).

If the eventCode field is not populated or is populated with a value unknown to the Alert Gateway,
the required category field will be used by the Alert Gateway to determine what text phrase to be
transmitted to the CMSP gateway.

Emergency message originators and the National Weather Service are encouraged to utilize codes
for eventCodes. These codes should be known by the Alert Gateway and have appropriate text
phrases associated with them to be transmitted to the CMSP gateway. The CMSAAC
recommends that a process be developed by which new event codes in addition to the standard
SAME and CAP event codes can be developed and registered.

The CMSAAC recommends that the affected area be generated from the optional geocode field. If the
optional geocode field is missing, the polygon or circle elements will be used to determine the associated
geocodes and the corresponding affected area description. The CMSAAC further recommends that a
process be developed by which new geocodes in addition to standard FIPS codes can be registered and
implemented in the Alert Gateway for deriving the affected area description.
The CMSAAC recommends that the response description will be taken from the optional responseType
CAP Field. If the field is not populated, the message should be transmitted with the text string “Check local
media for info” applied. The CMSAAC further recommends that a process be developed by which new
responseType Codes in addition to the standard CAP response type codes can be developed and registered.
The CMSAAC recommends that the expiration time will be determined from the optional expires CAP
field. If this field is not populated, local guidelines will be applied by the Alert Gateway as to when the
message is no longer in effect.
The following table defines the text string associated with the CAP value fields used to generate the
CMAM:

Table 5-1
What is happening
CAP Field
category

CAP Value Field Mapping to Text

Value
Met
Safety
Fire
Geo
Security
Rescue
Health
49

Text String
Severe Weather Warning
Public Safety Warning
Fire Warning
Geologic Warning
Security Warning
Rescue Alert
Health Warning

Commercial Mobile Alert Service Architecture and Requirements

eventCode

Env
Transport
TOR
VOW
SVR
EQW
TSW
BZW
DSW
FFW
HWW
HUW
TRW
WSW
CFW
FLW
FRW
SMW
AVW
CDW
CEM
HMW
LEW
CAE
NUW
RHW

Environmental Warning
Transport Alert
Tornado Warning
Volcano Warning
Severe TStorm Warning
Earthquake Warning
Tsunami Warning
Blizzard Warning
Dust Storm Warning
Flash Flood Warning
High Wind Warning
Hurricane Warning
Tropical Storm Warning
Winter Storm Warning
Coastal Flood Warning
Flood Warning
Fire Warning
Special Marine Warning
Avalanche Warning
Civil Danger Warning
Civil Emergency
HazMat Warning
Police Warning
AMBER Alert
Nuclear Power Plant Warning
Radiological Hazard Warning

What area is affected
Text String
“in this area”
When the alert expires
CAP Field
expires

What action should be taken
CAP Field
responseType

Who is sending the alert
CAP Field
sender

Value
The expiration time of the
information of the alert
message. The date and time
is represented in [dateTime]
format (e. g., “2002-0524T16:49:00-07:00” for 24
May 2002 at 16:49 PDT).
Value
Shelter or SPW
Evacuate or EVI
Prepare
Execute
Avoid Hazard 8
Value
Identifies the originator of this
alert. Guaranteed by assigner
to be unique globally; e.g.,
may be based on an Internet

Text String
Translated by the Alert
Gateway to an event expires
time in a 12 hour/Time zone
format (i.e., Until7:00AM PDT)

Text String
Take Shelter Now
Evacuate Now
Prepare for Action
Execute Action
Avoid Hazard
Text String
Translated by the Alert
Gateway to an acronym or
short abbreviation picked by
the sender

This value is recommended for CMAS use only pending inclusion into the CAP standard by the responsible
standards body.
50

Commercial Mobile Alert Service Architecture and Requirements

domain name - could also
come from the sender’s name
in the Trust Model.

Note: URLs, phone numbers,
and email addresses are not
sent to the mobile device.

1
2

5.3.2.1

Generating CMAM from Free Form Text

3
4
5
6
7
8
9
10
11
12
13

The CMSAAC recommends that a capability be provided for Alert Initiators to generate free form text
consistent with the text profile of Section 6.2, below. The CMSAAC further recommends that the Alert
Gateway have a mechanism to determine when the free form text should be used instead of the
automatically generated CMAM described in Section 5.3.2 above. The Alert Gateway mechanism is
subject to the implementation of the Alert Gateway and the policy of the authorized government entity.

14
15
16
17
18
19
20

The CMSAAC recommends that the FCC establish a forum that includes the CMSPs to develop the Alert
Gateway mechanism and policy for free form text-based CMAMs that will be subject to final approval of
the CMSPs. This policy would encompass specific decision points at the Alert Gateway such as: the
message length does not exceed the maximum character limit, the message contains no phone numbers or
URLs which would encourage mass access of the wireless network, the message contains all the necessary
elements of an effective message referenced in section, etc. If any of the decision points are not met, the
automatically generated message would be issued to the CMSP instead of the free form text.

21
22
23

The CMSAAC recommends that the Alert Gateway issue automatically generated CMAMs for alerts other
than presidential and AMBER Alert messages until free form CMAMs meet the policies established for the
Alert Gateway.

24
25
26

If the use of free form text messages becomes problematic or induces network disruptions in practice, the
Alert Gateway mechanism and policy would need to be modified to further restrict the issuance of free
form text messages or to utilize only automatically generated CMAMs.

27
28

The free form text for the CMAM should be included as a parameter of the CAP message with the
valueName indicating “CMAMtext”.

29
30
31
32

The CMSAAC further recommends that training be provided to Alert Initiators on generation of
meaningful CMAM which provides sufficient information on the mobile devices. It is recommended that
the above mentioned forum participate in the development of the training program for free form text
targeted for CMAMs.

33
34
35
36
37
38
39
40
41
42
43
44

As indicated in the above section, the generation of CMAM using CAP fields may not provide flexibility to
Alert Initiators to tailor the CMAM content to a specific alert event where only an event category is
available such as a “security warning”. In addition, Alert Initiators may want to provide specific response
information above what is available in the CAP responseType field.

5.3.3

Presidential Message and AMBER Alert

There are two additional special cases where automatic text generation at the Alert Gateway would not be
practical. These are the Presidential Alert message and AMBER Alerts. The CMSAAC recommends that:
1.

They may be identified by either by a code in the optional CAP eventCode field – EAN for
Presidential Alert and CAE for AMBER Alert - or by the required CAP sender field. Presidential level
messages are not restricted to nationwide only alert messages. The Presidential level message may
contain polygon, circle, GNIS, or geocode information to designate the targeted alert area.

The free text message would be presented to the Alert Gateway in a free text CAP field. This free text
message would be transmitted to the CMSP gateway. For Presidential alerts, the Alert Gateway may
51

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11

use a generic statement such as “The President has issued an emergency alert. Check local media for
more details”.
3.

It may be desirable for some AMBER Alert messages to include specific information such as a vehicle
license plate. The National Center for Missing and Exploited Children (NCMEC) should be
authorized to formulate unique free-form message text for CMAS.

These two special cases will use the normal processes for sending messages to the Alert Aggregator
(i.e., use of CAP messages) and will be treated as any other emergency alert initiated message except
as specified above and in Section 2.2.2 above.

5.3.4

12
13
14
15
16
17

Recommended Message Initiator Training

In order for emergency message initiators to develop and transmit effective emergency messages, within
the character length limits of the CMAM, the CMSAAC recommends that alert initiator training on
consistently populating CAP fields and generating CMAM be accomplished via the credentialing process
(See Section 8.1 below).

5.4

Recommendations for Geo-Targeting of CMAS Alerts

19
20
21
22
23
24

The CMSAAC acknowledges that it is the goal of the CMAS for CMSPs to be able to deliver geo-targeted
alerts to the areas specified by the Alert Initiator. 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. The CMSAAC further recognizes that CMSPs
currently have limited capability to deliver geo-targeted alerts.

25
26

Based upon current capabilities, the CMSAAC recommends the following for geo-targeting of CMAS
alerts:

27
28
29
30
31
32
33
34
35

36
37
38
39
40
41
42
43
44
45
46
47
48

In order to expedite initial deployments of CMAS an alert that is specified by a geocode, circle or
polygon (See Section 10.4) will be transmitted to an area not larger than the CMSP’s
approximation of coverage for the county 9 or counties with which that geocode, circle, or polygon
intersects. Some wireless technology RF propagation areas, for systems such as paging systems or
multi-county cell sites, may greatly exceed a single county. In these instances, CMSPs will
support geo-targeting subject to the limitations imposed by their technology. Cell sites’ / paging
transceivers’ physical location within the alert area may be used to determine the initial predefined
alert areas. The CMSP is not required to perform RF coverage mapping of cell sites / paging
transceivers to initial alert areas.
a.

49
50

A CMSP may elect to target smaller areas. CMSP may elect to target CMAM for
distributions to predefined alert areas smaller than a county and may use GNIS codes,
polygon, or circle information to identify a predefined list of cell sites / paging
transceivers within the alert area. In the interim period before the availability of
dynamic targeting, the CMSAAC recommends that certain urban areas with populations
exceeding 1,000,000 inhabitants or with other specialized alerting needs be identified for
priority consideration regarding implementation of more precise geo-targeting. The
CMSAAC further recommends that a process be established by the Alert Gateway
operator and the CMSPs to identify no later than August 2008 those initial areas that
should be given such priority treatment for more precise geo-targeting. The CMSAAC
recognizes the desire to move forward with this process on a small number of areas with
particularly urgent alerting needs as soon as possible. The CMSAAC recommends that
Section 604 funding be provided to FEMA for this purpose.

The CMSAAC recognizes that the use of predefined sets of cell sites frequently will not optimally
cover the alert area desired. Therefore, the CMSAAC recommends that the FCC encourage

County, parish or equivalent jurisdictional area.
52

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8

DHS/FEMA, in concert with CMSPs, to immediately initiate the research, development, testing,
and evaluation program referenced in Section 604 of the WARN Act. Section 604 requires DHS
to establish a program to develop innovative technologies that will allow CMSPs to efficiently
transmit geo-targeted CMAMs to the public. The CMSAAC further recommends that CMSPs
work with this DHS program to evaluate the feasibility and implementation issues associated with
proposed solutions to increase geographic targeting specificity. Finally, the CMSAAC
recommends that the FCC assess the progress of the CMSP geo-targeting as part of the biennial
review process.

9
10
11
12
13
14
15

The architecture to support CMAS shall not require the CMSPs to open the configuration,
interfaces and topology of their network including cell or paging transceiver towers to any third
parties, nor provide subscriber information or data outside their network. A CMSP shall not be
required to report cell site / paging transceiver information, coverage information, or any RF
properties of their respective networks. The CMSP shall be the sole agent responsible for
determining which network facilities, elements, or locations are involved in transmitting an alert to
a mobile device.

16
17

Transmission of alerts shall be to two-dimensional areas. There shall not be any altitude or ceiling
component.

5.5

19
20
21
22
23
24
25
26
27
28
29
30
31
32

Requirements and Recommendations on Needs of
Users, Including Individuals with Disabilities and the
Elderly

The WARN Act requirements for the establishment of the Commercial Mobile Service Alert Advisory
Committee membership specifically call for representation from “national organizations representing
individuals with special needs, including individuals with disabilities and the elderly”. 10
During its work, the CMSAAC reviewed input from members on accessibility considerations. Most of the
following requirements benefit all subscribers in an emergency.
It is recognized that not all wireless devices have the features to support all recommendations, but
manufacturers are strongly encouraged to implement those recommendations that are technically feasible,
so that their mobile devices can accommodate as many users as possible for emergency alerting.

5.5.1

33
34
35
36
37
38
39
40
41
42
43
44
45

General Requirements

In order to notify mobile service subscribers that an emergency alert message has been received on the
mobile device, the CMSAAC recommends that the CMAS support a common audio attention signal and a
common vibrating cadence to be used solely for CMAMs. These alerting mechanisms must be distinct from
all other audio alerting signals and vibrations available in the mobile device and must not be able to be
selected or modified by the user for any other purpose. The CMAS audio attention signals and vibration
cadence signals as defined in Section 7.2 below are applicable to all mobile devices which support CMAS
including any specialized mobile devices for individuals with special needs.
In addition, the CMSAAC recommends that the user should not be required to remember or use a unique
command to turn off the notification of the CMAM. A familiar command, consistent with the other
commands used for call or message handling on the mobile device, is recommended.
10

Beyond the WARN Act, consideration may be given to legislation such as Title II of the Americans With
Disabilities Act which requires accessibility to state and local government programs and communications; Section
504 of the Rehabilitation Act which requires accessibility of Federal government programs; Section 255 of the
Communications Act which requires accessibility in telecommunications products where readily achievable; and
Section 508 which applies to Federal government purchase of wireless devices.
53

Commercial Mobile Alert Service Architecture and Requirements

5.5.2

User Needs Requirements

5.5.2.1

Alert/Attention Signal

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

A unique vibration cadence (if supported by the mobile device) should be provided as well as a unique
audio attention signal. If both are available, the two modes do not need to be activated simultaneously but
will follow the user’s settings in the handset. If the handset supports dual activation the signals will be
simultaneous according to user settings, but otherwise will be separate signals. The vibration cadence for
the alert signal should be noticeably different from the default cadence of the handset.
For devices that have polyphonic capabilities, the CMSAAC recommends that the audio attention signal
should consist of more than one tone, all of which are to be in the low frequency range below 2 kHz, and
preferably below 1 kHz. For devices which have only single frequency audio alert tone capability, it is
recommended that the audio alert tone be in the low frequency range below 2 kHz. The CMSAAC further
recommends, subject to mobile device capabilities, that the signal have a temporal pattern (on-off pattern)
to make it easier to detect, particularly in noisy conditions and by people with hearing loss. See Section 7
below for additional information.
An audio attention signal starting with a lower intensity and going to a higher intensity during the tone
sequence may effectively get attention while endeavoring to avoid unduly startling the message recipient.
Some mobile devices may support this capability; however, such a capability is controlled by the subscriber
preferences for audio attention signal settings; this capability is not applicable to all mobile devices and
should be implemented at the discretion of the mobile device vendors.

5.5.2.2

Message Content

The CMSAAC makes the following recommendations regarding message content:
General Guideline: alert initiator use clear and simple language whenever possible, with minimal use of
abbreviations. The most important information should be presented first.
Text messages: Follow General Guideline
Audio messages: Follow General Guideline. The alert initiator must insure abbreviations are spoken as
full words.
Video messages: Follow General Guideline.
Multimedia messages: The alert initiator should provide ample text and audio to explain images such as
maps, so that message recipients understand the content of the graphics/images.

5.5.2.3

Output Mode/Display

The CMSAAC makes the following recommendations regarding output mode/display:
General Guideline: The mobile device should provide an easy way to allow the user to recall the message
for review.
Outside the scope of CMSAAC are alternate delivery mechanisms that would enable a CMAS-registered
person to sign up with a third party for alternate format message delivery. This would provide the means to
access speech delivery for people who do not have text-to-speech (TTS) functionality in their phones, and
would enable delivery of American Sign Language (ASL) if available and supported by the user's handset
and service. The CMSAAC recommends that the Alert Aggregator have the capability to deliver alerts to
third party services in order for them to deliver accessible alerts to users with special needs.
54

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

The need to support languages other than English is recognized. See Section 5.7 Multi-Language CMAS
Alert Recommendations below for further information.
Text Messages:
The mobile devices should use a font to make the message easily readable. Per the American Foundation
for the Blind, the goal in font selection is to use easily recognizable characters, either standard Roman or
Sans Serif fonts. Another good choice is Arial. Avoid decorative fonts.
The use of color should be avoided for the purpose of conveying information, as some people are colorblind, and some devices do not display color.
If technically feasible, the mobile device display should provide high contrast display and provide
adjustable font size.
One area of particular concern is that people who are blind or visually impaired will be most underserved
by a solely text-based CMAM. The Committee recognizes that these subscribers could be best served by
having the CMAM made available in speech format. There are mobile devices and software on the market
with screen reading and text-to-speech conversion capability. It is agreed that such specialized mobile
devices, which are geared for people who are blind and who have low vision, could be a solution. 11 The
CMSAAC recommends that participating CMSPs who elect to transmit CMAS alert messages strongly
consider offering this capability.
In mobile devices/software that includes capabilities to support text-to-speech access, the CMAS text
should be accessible to the screen-reading functions in phones that are capable of generating text- tospeech. The opt-out menus on displays also should be available to these screen readers. The CMSAAC
recommends that the CMAS text is accessible to these screen readers when CMAS capability is
incorporated in those devices.
Future Audio Alert Message:
Follow the general guideline. Alert initiators should insure that speech is enunciated and presented at a
slow pace. Alert initiators should provide a text version along with the audio version. Note this is not the
text-based alert; this is a multimedia alert that contains both a text and audio component consistent with the
multimedia profiles.
Future Video Alert Message:
Follow the general guideline. Alert initiators should provide text versions of the audio content of video
alerts. CMSPs and mobile device vendors should consider appropriate methods for delivery and allowing
users the ability to display this associated text on mobile devices as technology evolves and video and
captioning capabilities become available. Also, the alert initiator should provide an audio description of the
video content as a separate multimedia audio component consistent with the multimedia profiles.
Future Multimedia Alert Message:
Follow the general guideline. The alert initiator should provide all information in text and graphical form
as part of the multimedia components to the alert message. The alert initiator should provide an audio
description of the important information supplied in the graphic, which is a separate multimedia component
consistent with the multimedia profiles.

5.5.2.4

Behavior on Receipt of a Message

53
11

For more information, the American Foundation for the Blind (AFB) is an authoritative resource for accessible
devices and related technology developments: http://www.afb.org
55

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5

It is desirable to have the CMAM prominently presented on the mobile device without user interaction
when the alert message is received. To turn off the notification of the CMAS message, a familiar command
consistent with the other commands used for message handling on the mobile device is recommended. It is
best to avoid requiring the subscribers to remember and use a unique command or command sequence. The
need to scroll or manipulate the device should be minimized.

5.5.2.5

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

CMAS-Related Print and Online Materials

As important to the accessibility of the CMAS is the accessibility of any CMAS-related consumer
information in print or electronic form. Providing information that incorporates accessibility solutions for
individuals with special needs may also bring benefits to the general population, not just users with
disabilities, as studies of multimodal learning have shown. Listed here are a variety of available resources
that present solutions to accessibility obstacles in formats designed to easily educate and assist publishers.
The Web Accessibility Initiative (WAI) develops strategies, guidelines, and resources to help make the
Web accessible to people with disabilities. The following WAI resources are intended to provide basic
information for people who are new to Web accessibility. The W3C – World Wide Web Consortium (W3C)
Web Content Accessibility Guidelines are available at http://www.w3.org/WAI/
The principles of universal design — designing to meet the needs of as many users as possible — provide a
new dimension for improving the usability of electronic materials for everyone. The Carl and Ruth Shapiro
Family National Center for Accessible Media at WGBH developed Accessible Digital Media Design
Guidelines for Electronic Publications, Multimedia and the Web, available at
http://ncam.wgbh.org/publications/adm/
The above resources are provided for informational purposes to ensure the accessibility of all CMAS
related print and web content. It is not the intent of the CMSAAC to make recommendations for existing
web content or web content not associated with CMAS.
For future multimedia capabilities, if web content is delivered to the mobile device, consideration should be
given to the proposed World Wide Web Consortium (W3C) Mobile Web Best Practices 1.0.

5.5.3

30
31
32
33
34
35
36
37
38
39
40

Subscriber CMA Opt-Out Recommendations

As stated in the WARN Act, the CMA subscriber opt out process may be supported by a CMSP that elects
to transmit.
o

Opt-out is defined in Section 602(b)(2)(E) in the WARN Act as “the capability of preventing the
subscriber's device from receiving such alerts, or classes of such alerts, other than an alert issued
by the President” 12
“Receiving such alerts” may also be interpreted to “notify and display to the user of such alerts” as
the mobile device may actually receive the alert but not present it to the subscriber

As noted in Section 5.1 above, there are three classes of CMAS Message categories:

41
42
43

1.
2.
3.

44
45
46
47

Presidential-level
Imminent threat to life and property
Child Abduction Emergency or “AMBER Alert”

Presidential-level messages must always be transmitted and are not eligible for the opt-out procedure.
Imminent Threat alerts are messages where the CAP severity field is Extreme or Severe, the CAP urgency
field is Immediate or Expected, and the CAP certainty field is Observed or Likely. AMBER Alert messages
are considered a different message classification and are treated separately..

WARN Act §602(b)(2)(E).
56

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

The CMSAAC recommends that CMSPs shall offer their subscribers a simple opt-out process that is based
on the classification of imminent threat and AMBER Alerts. Except for presidential messages, which are
always transmitted, the process should allow the choice to opt-out of:
•
•
•

4
5
6
7
8
9
10
11
12

All messages 13,
All severe messages 14,
AMBER Alerts 15

Because of differences in the way CMSPs and device manufacturers provision their menus and user
interfaces, CMSPs and device manufacturers shall have flexibility on how to present the opt-out choices to
subscribers.

5.6

13
14
15
16
17
18
19
20
21
22

Recommendations for CMAM Transmissions

The CMSAAC recommends that the CMAM be retransmitted into an effected area until the alert expires.
This will provide the alert to those that might have missed the initial broadcast alert, e.g., been in the
process of a voice call, those that might have had their mobile device turned off when the alert was issued
or those that might be entering the area after the alert was issued.
The interval and frequency of transmission of CMAM performed by the CMSP is based upon balancing the
capabilities of the CMSP specified delivery technology and various factors, such as:
- Number of simultaneous active alerts

- Number of languages

- Mobile device battery life

- Latency from alert initiator to receipt by first mobile device

- Notification to subscribers entering alert area

- Limitations of delivery technology

- Configuration of delivery technology and mobile devices

- Impact to normal call processing.

30
31
32

Therefore, the CMSAAC recommends that the CMSP determine the frequency of retransmissions based
upon the considerations and optimization of the above mentioned factors.

5.7

33
34
35
36
37
38
39
40
41

Multi-Language CMAS Alerts Recommendations

The WARN Act requires the CMSAAC to submit to the Commission recommendations “for 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.” 16
Provision has been made in the CMAS architecture to support language extensions, for example the C
interface contains fields to identify language and character encoding (see Section 10.4, below). Such
extensions are reserved for a time at which the engineering impact of additional language sets is

Presidential messages will still be received
Extreme messages, AMBER Alerts and presidential messages will still be received (Extreme messages are those
messages where the CAP severity field is Extreme, the CAP urgency field is Immediate, and the CAP certainty field
is Observed or Likely).
15
All other messages will still be received.
16
WARN Act §603(c)(4)).
57
14

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

understood. The biennial review committee shall continue to study the feasibility of broadcasting alerts in
languages other than English.
It is recognized that there is a strong desire for the CMAS to support Spanish in addition to English. A
CMSP may choose to transmit alerts received in languages other than English based on the capabilities of
the technology the CMSP has deployed to support CMAS alerts, the capabilities of the mobile device, the
CMSP’s policy, and the definition of the the single unified Federal policy for the support of alerts in
multiple languages. In addition, the Alert Gateway would need to be able to generate CMAM in multiple
languages.
The CMSAAC recommends that CMSPs not be required to give notification in its election to transmit
alerts, at point of sale or through any other means, or to the CMSP’s subscriber base for not supporting the
transmission in languages other than English.
A fundamental requirement for the optional support of languages other than English is that the CMAM
must be delivered to the CMSP in the language that it is to be delivered and in the CMAS format. At the
current time, there shall be no language translation in the CMSP network or in the mobile device. This
requirement should be reviewed as technology improvements are developed.
The CMSAAC has analyzed the technical feasibility of supporting multilanguage CMAS alerts on the
various delivery technologies and has determined that support of languages other than English is a very
complex issue. Fundamentally the existing air interfaces of CMSPs have technical limitations and the
support of multiple languages may result in a significant impact to capacity and latency due to these
limitations.
In addition, an important question is how many languages should be considered? On a National basis, only
Spanish exceeds 1% of households. On a local basis, however, there are potentially more than 37 languages
that exceed 1% of households which would require more than 16 different character sets to be supported in
the mobile device. This raises issues such as character set limitations, the amount of CMAS alert message
traffic that would need to be delivered in multi-languages, bandwidth limitations, increased cost and
complexity, mobile device capabilities and deployment impacts. Additional character sets to support
multiple languages also will potentially limit the amount of data that can be transmitted; for example, some
character sets require 2 Bytes per character versus 1 Byte per character, and thus 90 characters available in
the text profile for a CMAM now reduces the text message to 45 characters. Additional languages increase
the cost and complexity both in the mobile device and in the CMSP network. At the present time, the
CMSAAC believes there are fundamental technical problems to reliably implement any languages in
addition to English.

5.8

CMAS Reception Control on Mobile Devices

CMAS reception control is required where subscribers and/or CMSPs should be allowed to control the
reception of CMAS alerts via control of the delivery technology (e.g., broadcast) on a CMAS-capable
mobile device. The CMSAAC recognizes the WARN Act requirements of not being able to opt-out of
Presidential messages. However, the primary justifications for allowing a subscriber and/or CMSP to
control the CMAS delivery technology capabilities on the mobile devices include:
a.

Providing the ability of not presenting CMAS alert messages to users that may not understand or may
experience undue alarm such as parents wanting to suppress this service for young children or the
elderly.

Disabling the broadcast capability when traveling to locations where the CMAS services are not
desired or not supported and thus preserving battery life in normal circumstances.

In the presence of the CMSP radio signal, potential savings on battery life, which may be critical in an
emergency or disaster situation especially where power is not available to recharge the mobile device.
58

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Disabling the broadcast capability for mobile devices that are being used for special applications where
the CMAS service is not applicable such as a backup notification method for in-home security systems.

Being able to disable the broadcast capability for CMSPs that elect not to transmit alerts in whole or in
part.

Based upon the above, the CMSAAC recommends:
1.

The CMSP will have the capability to enable or disable the broadcast capabilities or CMAS
functionality on any of their associated mobile devices. This capability is under CMSP control
mechanisms such as mobile device provisioning, and the CMSP shall be required to give notification
to the subscribers as defined in Section 3.4 above.

The mobile device user may have the capability on their mobile device to disable the delivery
technology for the CMAS alert messages. The execution of this capability by the subscriber shall
require confirmation of the action by the subscriber and there are no additional CMSP notification
requirements as described in Section 3.4 above.

5.9

Roaming

The CMSAAC recommends that roaming be supported only on an intra-technology basis. For example:

Roaming GSM subscribers receive CMAS alerts from GSM operators in the serving market.

Roaming CDMA subscribers receive CMAS alerts from CDMA operators in the serving market.

24
25

If a CMSP elects not to support CMAS alerts, subscribers from other CMSP will not receive CMAS
alert messages when roaming onto that CMSP’s network.

26
27
28
29

If a CMSP elects not to support CMAS alerts and subscribers from that CMSP roam onto another
CMSP network which does support CMAS alerts, that roaming subscriber will receive CMAS alert
messages only if their mobile device is configured to receive CMAS alert messages with the delivery
technology of roamed-to CMSP network.

30
31
32

Inbound roamers may be supported if the mobile device is configured for, is eligible to receive and is
technically capable of receiving CMAS alert messages with the delivery technology of the serving
CMSP network.

Commercial Mobile Alert Service Architecture and Requirements

1
2

6 Service Profiles

3
4
5

The CMAS architecture and recommendations are based upon the principles of service profiles.
Commercial mobile operators may utilize any broadcast technology to the mobile devices which comply
with the service profiles. The following service profiles are defined

•

Text Profile

•

Streaming Audio Profile (future capability)

•

Streaming Video Profile (future capability)

•

Downloaded Multimedia Profile (future capability)

10
11
12

The CMSAAC recommends that each CMAS alert sent to the CMSP Gateway contain, at a minimum, the
attributes for the text profile. Optionally, there may be multiple streaming audio, streaming video, and/or
downloaded multimedia attributes associated with the CMAS alert sent to the CMSP Gateway.

13
14

Specifically, the following will be the service profiles associated with a CMAS alert sent to the CMSP
Gateway:

•

One Text Profile

•

Zero or more Streaming Audio Profiles

•

Zero or more Streaming Video Profiles

•

Zero or more Downloaded Multimedia Profiles

19
20

The following section provides general recommendations and conclusions on text, audio, video, and
multimedia resources.

6.1

Conclusions on Text, Audio, Video & Multimedia
Resources

22
23
24
25
26
27
28

The CMSAAC recommends that the formats for future streaming audio, streaming video, and multimedia
be defined at point where implementation and deployment of these technologies have reached a point
where a standard set of formats can be identified, e.g., at the initial biennial review described in Section 5
above. The CMSAAC also recommends that the alert initiation systems do not implement any coding
formats for these types of resources until the full impact to the end-to-end CMAS system is understood.

29
30

The CMAS service profiles for text, audio, video, and multimedia messages are for the transmission of text
data, audio files, video files, and multimedia files and not for the presentation of real-time content.

The CMSP networks are outside the scope of the Trust Model of the government alerting infrastructure.

32
33

The Alert Gateway is responsible for collecting and assembling all text, audio, video, and multimedia
components of the CMAS messages to be given to the CMSPs for transmission.

34
35
36
37

If the CAP message includes a Resource Element that includes an URI, it is not expected that the
CMSPs will be required to retrieve the file specified by the URI. Rather, the Alert Gateway will
retrieve the associated file during the collection and assembly process for the CMAS alert message
for retrieval by the CMSPs.
60

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4

The CMSAAC recommends that the government alerting infrastructure be aligned with the capabilities and
requirements as defined under the CMAS.

5
6
7

Any audio, video, and multimedia files collected for the CMAS alert messages must be provided
to the CMSPs in a standard set of formats.

The above referenced initial CMAS service profiles are not capable of providing real-time
multimedia broadcasts including a Presidential audio alert.

6.2

Text Profile

Support of the text profile is the minimum requirement for any CMSP which elects to support CMAS.

9
10

This information is passed from the Alert Gateway to the CMSP Gateway and may include attributes that
are generated by the CMAS alert originator.

Table 6-1

Text Profile

Service Profile: Text_Universal_Service_Profile
Attribute Name

Attribute Definition

Note

Purpose

Common denominator for text messages

Maximum Payload
Size

120 bytes (As noted in Section 5.3.1, the biennial
review committee shall review whether the
character limit profile may be increased.)

Maximum Displayable
Message Size

90 characters for an English language CMA encoded Languages other than English, or coding
other then 7-bit coding, will result in a
with 7-bit encoding. (As noted in Section 5.3.1,
change to the maximum number of
the biennial review committee shall review whether
characters supported
the character limit profile may be increased.)

Data Coding Scheme

UTF-8 as defined in IETF RFC-3629

Size is estimated

The text on 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
CMSP Gateway to translate to any
character format encoding required by
the CMSP selected delivery technology.

12
13

6.3

Streaming Audio Profile (future capability)

14
15
16

The streaming audio profile defines the attributes for the support of streaming audio based CMAS alerts.
Support of the streaming audio profile is optional for any CMSP which elects to support CMAS and is
dependent on the technology selected by the CMSP and mobile device capabilities.

17
18

This information is passed from the Alert Gateway to the CMSP Gateway and may include attributes that
are generated by the CMAS alert originator.

Table 6-2

Streaming Audio Profile

Service Profile: Streaming_Audio_Service_Profile
Attribute Name
Purpose

Attribute Definition
Define service profile for streaming audio messages

Note

Commercial Mobile Alert Service Architecture and Requirements

Service Profile: Streaming_Audio_Service_Profile
Attribute Name

Attribute Definition

Maximum Size

Note

Based upon the authorized government entity policy

Size of the streaming audio file is
dependent on the file type and encoding
algorithms.
Size of CMAS alerts with streaming audio
components are much larger than text
based CMAS alerts and, therefore, could
have greater impact to bandwidth
requirements, message latency, etc.

C Interface Data
Coding Scheme

Identification of the standard format of the streaming
audio file being retrieved by the CMSP Gateway

See reference model

C Interface Audio File
Reference

Issue of audio file transmissions remains to be
addressed.

The contents of this attribute are based
upon the streaming audio file being
pulled by the CMSP Gateway from the
Alert Gateway.

1
2

6.4

Streaming Video Profile (future capability)

3
4
5

The streaming video profile defines the attributes for the support of streaming video based CMAS alerts.
Support of the streaming video profile is optional for any CMSP which elects to support CMAS and is
dependent on the technology selected by the CMSP and mobile device capabilities.

6
7

This information is passed from the Alert Gateway to the CMSP Gateway and may include attributes that
are generated by the CMAS alert originator.

Table 6-3

Video Profile

Service Profile: Streaming_Video_Service_Profile
Attribute Name

Attribute Definition

Purpose

Define service profile for streaming video alert
messages

Maximum Size

Based upon the authorized government entity policy

Note

Size of the streaming video file is
dependent on the file type and encoding
algorithms.
Size of CMAS alerts with streaming video
components are much larger than text
based CMAS alert messages and,
therefore, could have greater impact to
bandwidth requirements, message
latency, etc.

C Interface Data
Coding Scheme

Identification of the standard format of the streaming
video file being retrieved by the CMSP Gateway

See reference model

C Interface Video File
Reference

Issue of video file transmissions remains to be
addressed.

The contents of this attribute are based
upon the streaming video file being
pulled by the CMSP Gateway from the
Alert Gateway.

Commercial Mobile Alert Service Architecture and Requirements

6.5

Downloaded Multimedia Profile (future capability)

2
3
4
5
6
7

The downloaded multimedia profile defines the attributes for the support of CMAS alerts with multimedia
files (e.g., graphics, photos, maps, animation) which are to be downloaded to the mobile device. Support of
the downloaded multimedia profile is optional for any CMSP which elects to support CMAS and is
dependent on the technology selected by the CMSP and mobile device capabilities. The multimedia files
for download to the mobile device are distributed using broadcast mechanisms instead of point-to-point
mechanisms based upon by the CMSP selected technology.

8
9

This information is passed from the Alert Gateway to the CMSP Gateway and may include attributes that
are generated by the CMAS alert originator.

Table 6-4

Downloaded Multimedia Profile

Service Profile: Downloaded_Multimedia_Service_Profile
Attribute Name

Attribute Definition

Purpose

Define service profile for CMAS alerts with
multimedia files for download to the mobile device.

Maximum Size

Based upon the authorized government entity policy

Note

Size of the multimedia file for downloaded
is dependent on the file type and
encoding algorithms.
Size of CMAS alerts with multimedia
components for download to the mobile
device are much larger than text based
CMAS alert messages and, therefore,
could have greater impact to bandwidth
requirements, message latency, etc.

C Interface Data
Coding Scheme

Identification of the standard format of the
multimedia file being retrieved by the CMSP
Gateway

C Interface Multimedia Issue of multimedia file transmissions remains to be
File Reference
addressed.

See reference model

The contents of this attribute are based
upon the multimedia file being pulled by
the CMSP Gateway from the Alert
Gateway.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

7 Mobile Device Functionality for CMAS Alerts
This section describes the impact to the mobile devices for the support of CMAS alerts and organized into
the following topics:
•
•
•
•

General Requirements on Mobile Device Functionality
Mobile Device Audio Attention Signal & Vibration Cadence Recommendations
CMAS Functionality on Mobile Device
Impact to Mobile Device Battery Life

7.1

General Requirements on Mobile Device Functionality

The CMSAAC recommends that the CMSP and the mobile device vendors have the flexibility in the design
and implementation of mobile devices in order to take the maximum advantages of advances in mobile
device technologies and to account for the evolution of mobile devices and the capabilities of the future.
The CMSAAC further recommends that:

Mobile device behavior is outside the scope of the WARN Act and, therefore, is not subject to
recommendations by the CMSAAC.

21
22

There be a common audio attention signal and a common vibration alert cadence for CMAM. (See
Section 7.2 below)

23
24
25

The functionality and features of the mobile device after the receipt of the CMAM (e.g., message
storage, message expiration, alert presentation visual interface and user acknowledgement to the
mobile device of alert messages) will be CMSP and mobile device specific.

26
27

Legacy deployed mobile devices may not be supported. At a minimum, new CMAS functionality is
needed on future mobile devices.

New mobile devices will be introduced by normal market mobile device lifecycle replacement.

Some legacy pager devices may be able to be updated with over the air programming

30
31
32

Distribution of the CMAS alert messages to the CMSP’s subscribers will be unidirectional from the
CMSP network to the mobile device of the subscriber. There will not be any acknowledgement or
confirmation of receipt from the mobile device.

CAP messages will not be delivered to mobile devices of the subscribers.

34
35
36

7.2

Mobile Device Audio Attention Signal & Vibration
Cadence Recommendations

37
38
39

Currently most Americans are familiar with the current EAS audio attention signals on radios and
televisions which have been in use since the 1960s. Reproduction of this audio attention signal on mobile
devices is the most recognizable method to notify the American public of CMAS alert message.

40
41
42
43

The EAS uses a two tone system for audio alerts which is a combination of 853Hz and 960Hz sine waves.
For devices capable of supporting dual tone EAS audio attention signals, the CMAS audio attention signal
should sound as close to the EAS audio attention signals as can be feasibility achieved with the capabilities
of the mobile devices.
64

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

The single tone for the NOAA warning alarm tone for NOAA Weather Radios and commercial broadcast
stations is 1050Hz. EAS audio attention signals on commercial broadcast stations are 8 to 25 seconds in
duration and the NOAA warning alarm tone is 8 to 10 seconds.

4
5
6
7
8
9

The CMSAAC recommends that temporal patterns of the CMAS audio attention signal should be supported
if technologically feasible. The recommended temporal pattern of the CMAS audio attention signal is one
long tone of approximately 2 seconds followed two short tones of approximately 1 second each with
approximately ½ second gap between tones. The entire sequence is repeated twice with approximately ½
second between repetitions. Temporal patterns of the CMAS audio attention signal are mobile device
manufacturer specific.

10
11
12

For devices that have polyphonic capabilities, the CMSAAC recommends that the audio attention signal
consist of the two EAS tones. For devices which have only single frequency alert tone capability, it is
recommended that the CMAS audio attention signal be in the low frequency range below 2 kHz.

13
14
15

The CMSAAC recommends that the vibration cadence for the CMAS alert signal be noticeably different
from the default cadence of the mobile device and should be similar to the temporal pattern of the audio
attention signal and is mobile device manufacturer specific.

16
17
18

If both CMAS audio and vibration cadence alerts are available, the two modes do not need to be activated
simultaneously but will follow the user’s settings in the mobile device; if the mobile device supports dual
activation the signals will be simultaneous according to user settings, but otherwise will be separate signals.

19
20
21
22

The CMSAAC recommends that neither the CMAS audio attention signal nor the vibration cadence
provided by the CMSP for the CMAS alert should be selectable by the subscriber for any mobile device
functions. However, the CMSAAC acknowledges that there is no way to prevent the subscriber from
downloading a ring tone that emulates the CMAS audio attention signal.

23
24
25
26

The CMSAAC recommended that the CMAS audio attention signal and the associated vibration cadence
shall not be used for any application other than CMAS. The CMSAAC further recommended that the
CMAS audio attention signal and the associated vibration cadence should be protected via copyright and/or
trademarks and should be available for appropriate use on free and non-discriminatory basis.

27
28

7.3

CMAS Functionality on Mobile Device

29
30

This section contains the CMSAAC’s conclusions and recommendations regarding the CMAS functionality
on the mobile device that would be needed to support CMAS alerts.

31
32

If the end user has muted the mobile device audio and alarms, the CMAS audio attention signal will
not be activated upon receipt of a CMAS alert.

33
34

If the end user has deselected or turned off the vibration capabilities of the mobile device, the special
emergency alert vibration cadence will not be activated upon receipt of a CMAS alert.

35
36
37

If the end user has both muted the mobile device audio and alarms and has deselected or turned off the
vibration capabilities of the mobile device, neither the CMAS audio attention signal nor the special
emergency alert vibration cadence will be activated upon receipt of a CMAS alert.

38
39
40

Subject to the limitations of the CMSP selected broadcast technologies and the mobile devices, the
presentation of the received CMAS alert message should take priority over other mobile device
functions except for the preemption of an active voice or data session.

41
42
43
44

If the end user does not acknowledge the CMAS alert to the mobile device, the mobile device should
support the capability to activate and deactivate the CMAS audio attention signal and/or should
activate and deactivate the special emergency alert vibration cadence, if mobile device has vibration
capabilities. The frequency and interval of the activation and deactivation of the CMAS audio
65

Commercial Mobile Alert Service Architecture and Requirements

1
2

attention signal and/or the special emergency alert vibration cadence is dependent on CMSP policies
and mobile device capabilities.

3
4
5

In order to minimize the possibility of network congestion and false alerts, mobile devices should not
support any user interface capabilities to forward received CMAS alerts, to reply to received CMAS
alerts, or to copy and paste CMAS alert contents.

6
7
8

The presentation of CMAS alert messages to the subscriber on the mobile device should be
distinguishable from any other types of textual messages received by the mobile device subject to
mobile device capabilities.

9
10

Color cannot be a required method for distinguishing CMAS alert messages from other types of
text messages on the mobile device since all mobile devices do not have color display capabilities.

Color cannot be used as the sole method for convening information. (See Section 5.5 above)

7.4

Impact to Mobile Device Battery Life

13
14

The CMSAAC recommends that the Alert Aggregator support a policy of ensuring that the aggregate
CMAM rate does not adversely impact mobile device battery life.

15
16
17

The CMSAAC recommends that the CMSPs give consideration to modifications to network infrastructure,
mobile devices and/or standards, and to the proper selection of the criteria below, in order to limit the
reduction of battery life.

18
19
20

This analysis was limited in scope to text based messages, and does not analyze the impacts of other
profiles, such as audio, video or multimedia. The delta impact on portable device battery life of text based
alert messages of CMAS depends upon the following input criteria:

Delivery Technology (GSM, UMTS, CDMA2000 1x, Flex, Re-Flex, etc.)

b) Initial system network parameters before implementation of broadcast messaging

d) Retransmission interval

Number of languages supported

Number of alerts sent

g) Alert Duration, and number of times the portable device alerts the user

Maximum latency to deliver the message over the E interface

28
29
30
31
32

Each technology implements text broadcast messaging differently. In addition, each technology is
deployed with different hardware and software, as well as, different standards releases. During the battery
life evaluation, these issues explain the wide range of reported battery life impact of text Broadcast
Messaging. The battery life impact of CMAS on a state of the art deployment of infrastructure and portable
devices targeting optimized battery life could be as high as 40% or more.

33
34
35

When using older technology or different network parameters, the impact to battery life can be quoted as a
lower percentage, although battery life will be lower than the optimized solution with cell broadcast
enabled.

36
37
38
39
40

Although there are limitations in today’s implementation of Cell Broadcast, it can be utilized for
transmission of Emergency Alerts. The impact to portable device battery life can be managed through
careful selection of the above parameters. The high impact parameters influenced by the CMSAAC are
maximum latency to deliver the message over the E interface, Retransmission interval, Number of
languages supported, Number of alerts sent, and Alert Duration.
66

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6

With modifications to network infrastructure, mobile devices and/or standards, and proper selection of the
above criteria, the reduction of battery life can be less than 10% of today’s capability for monitoring the
Cell Broadcast channel without sending alerts messages. These modifications could potentially adversely
the timeline given in Section 12.2.1 below. When alert messages are sent, e.g. a disaster situation with
multiple alerts sent from multiple agencies, the reduction of battery life increases proportionally to the
number of messages sent and can approach up to 40% of the battery life.

7
8
9

To design and deploy a system with the performance described above, modifications to the portable
devices, network infrastructure and/or standards are required. These changes are scheduled in the proposed
timeline for deployment of CMAS.

Commercial Mobile Alert Service Architecture and Requirements

1
2

8 Security for CMAS Alerts

8.1

Alert Interface & Aggregator Trust Model

8.1.1

Trust Model Definitions

5
6
7
8
9

The following definitions are offered for clarity and specificity.
•

Identity – A trusted agent will verify the identity of each individual that will be requesting
credentials.

10
11

•

Responsibility – The individual will have the duties of issuing public alerts and warnings on
behalf of their respective jurisdiction.

•

Jurisdiction – The area a person has authority to send public alert and warning messages

13
14

•

Authority – Any public servant that is permitted by their jurisdiction to send a public alert and
warning message.

15
16
17
18

•

Capability – The nominated individual must demonstrate the knowledge of process, content
and policy pertaining to the issuance of public alerts and warnings. The minimum requirement
shall be a national level computer based training course. States and or local jurisdictions may
require further training if they so desire.

19
20
21

•

Credential – A specified form of evidence that an individual has completed the verification of
identity, responsibility and capability. This credential will allow the individual to send or
countersign a public alert and warning message.

22
23

•

Certified system – will support the Trust Model and counter-signatory function to send public
alert and warning messages.

24
25

•

Countersigned – A public alert and warning message must be digitally signed by two
credentialed personnel for acceptance into the CMAS.

•

Originator – Can be a Federal, State, Tribal, or local jurisdiction.

8.1.2

Trust Model Requirements

28
29
30

The CMSAAC makes the following recommendations regarding Trust Model requirements:
1.

All messages will be attributed reliably to an individual sender.

31
32

All messages will be accepted from individuals holding a specified credential or from a certified
system which required individual credentials.

33
34
35

All messages must be countersigned by a second credentialed sender. All messages not countersigned
will be rejected and not be sent. The sender must be notified if the message was rejected for this
reason.

36
37

The CMSAAC recommends that a process be established by which credentials can be certified upon
demonstration of identity, responsibility and capability.

38
39

Identity, responsibility and capability must be recertified annually. All credentials will expire in 12
months.

40
41

All messages entered into the system will be logged, this log will be maintained for a reasonable period
of time to support an audit.
68

Commercial Mobile Alert Service Architecture and Requirements

1
2

The digital signatures will be bound to the message and carried from the originator to the Alert
Gateway.

3
4

The message transport layer from the originator to the Alert Gateway will utilize an existing open nonproprietary transport standard and shall be Internet Protocol based.

5
6
7
8
9

8.2

Alert Gateway Security Requirements

The CMSAAC recommends that the Alert Gateway be protected against the potential for misuse such as
hoax emergency alerts, illegal distribution of offensive content, Denial of Service (DoS/DDoS) attacks and
SPAM. The CMSAAC recommends the following requirements to achieve the necessary level of security:

10
11
12
13

The Alert Gateway will be subject to and administered in a manner consistent with the Trust Model
and shall be in compliance with Federal Information Processing Standard (FIPS) 199 and FIPS
200. The Alert Gateway shall also be in compliance with security requirements for National Critical
Infrastructure/Key Resources.

14
15
16
17

The Alert Gateway will be part of the government alert distribution network. The interface between the
Alert Aggregator and the Alert Gateway shall support the Trust Model specified in Section 8.1 above.
The C interface is outside the scope of the Trust Model and therefore the Alert Gateway shall support
standardized authentication and authorization mechanisms to interface with the CMSP Gateways.

18
19

A single authorized source such as a designated government agency, or their authorized agent, will
serve as the sole operator for the Alert Gateway.

20
21
22

The Alert Gateway will authenticate the source of all alert transactions. If the source cannot be
authenticated, the message will not be sent and a warning issued to the Alert Gateway’s monitoring
system.

23
24

The Alert Gateway will inform the alert originator via Alert Aggregator if the CMAS message was not
accepted by the CMSP Gateway.

25
26
27
28
29
30
31
32

8.3

Reference Point C Security

The CMSAAC recommends that the Reference Point C interface be IP based. Therefore the security of the
Reference Point C interface should be based upon standard IP security mechanisms such as VPN tunnels
and IPSEC functionality.

8.4

Reference Points D & E Security

The CMSAAC recommends that the security of the Reference Points D and E be based upon CMSP
policies and upon the capabilities of the CMSP selected delivery technologies.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4
5
6
7
8

9 CMAS Reliability & Performance
The CMSAAC recommends that, to the extent feasible, prior to the September 2008 CMSP Election, the
statistical data on peak and average alert traffic volume at least for the period October 2007 thru August
2008 be available to CMSPs to support the engineering considerations for the CMSP Gateway and air
interfaces. This statistical data needs to be available at the geo-targeted areas defined in Section 5.4 above.

9.1

Alert Gateway Performance Requirements

9
10
11

See Annex A – Anticipated Peak & Average CMAS Traffic Volume for anticipated peak & average CMAS
traffic volume. The CMSAAC makes the following recommendations regarding Alert Gateway
performance requirements:

12
13
14
15
16
17
18

Based on available historical data presented to the committee, and then applying a 2X factor, it is
estimated that no more than 25,000 alert messages per year will be delivered to the Alert Gateway for
transmission to the various CMSPs. It is also assumed that peak rates as high as 12,000 alert messages
per month and 6,000 alert messages per day are possible. For a given hour, it is also conceivable that
there can be an alert for every county in the U.S. and therefore the Alert Gateway should be capable of
receiving and processing 3,000 alert messages per hour and a peak rate of 30 alert messages per
second.

19
20

The Alert Gateway will have capabilities to monitor the system utilization for capacity planning
purposes and it shall be scalable to accommodate the need for additional capacity.

21
22

The Alert Gateway will provide a transmission control mechanism to buffer the CMAM traffic upon
receiving an overload warning from the CMSP Gateway.

23
24
25

The Alert Gateway will provide the capability for a CMSP or CMSP Gateway to temporarily disable
the transmission of all CMAMs to the CMSP Gateway. While CMAM delivery to CMSP Gateway has
been stopped, the Alert Gateway shall establish an alert queue for the specific CMSP Gateway.

26
27
28
29

The CMSP Gateway will notify the Alert Gateway to stop sending CMAM using an error
response as described in Section 10.4.6 below. Once the error condition has cleared, the
CMSP Gateway will notify the Alert Gateway to restart CMAM delivery and retry delivery of
CMAMs in the queue if the CMAMs have not expired.

30
31
32
33
34
35

The authorized government entity which manages the Alert Gateway will establish a process
where an authorized CMSP representative can provide notification of a planned or unplanned
outage of a CMSP Gateway and during that outage period, CMAMs are not delivered from
the Alert Gateway to that specific CMSP Gateway. During a planned or unplanned outage,
the ability to support test message across the Reference Point C interface will be supported as
defined in Section 10.4 below.

36
37
38
39

If the CMAM delivered over the Reference Point C interface was rejected by a CMSP Gateway due to
congestion or temporary transient error conditions, the Alert Gateway will establish an alert queue for
the specific CMSP Gateway and retry delivering it to the CMSP Gateway by a configurable interval,
e.g. every 30 seconds, if the CMAM has not expired.

40
41
42

There are two logical queues per CMSP Gateway, one logical queue for Presidential alerts and another
logical queue for all other CMAMs. The processing of the Presidential queue takes priority over the
non-Presidential queue.

Commercial Mobile Alert Service Architecture and Requirements

1
2

If an alert queue exists for a CMSP Gateway, all incoming alerts shall be placed into the queue based
upon the time the CMAM was received by the Alert Gateway.

3
4

The Alert Gateway will support separate alert queues for each CMSP Gateway so that queuing for one
or more CMSP Gateway shall not affect alerts delivery to all other CMSP Gateways.

The Alert Gateway will be designed to have the service availability of 99.999%.

6
7

10. System performance will be monitored in real-time 24 hours a day seven days a week to ensure all

levels of service are met and/or exceeded.

9.2

Alert Delivery Latency

9
10

The CMSAAC recommends that, since latency will require experience in deployment, end-to-end latency
requirements be addressed in the biennial review.

11
12
13
14

The CMSAAC recognizes the importance of delivering CMAMs as quickly as possible from the alert
initiators to the transmission within the alert area. The CMSAAC also recognizes that there are operational
characteristics of the CMSP Infrastructure which impact CMAM delivery latency. These operational
characteristics include the following factors:

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

Geo-targeting processing

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

It is difficult to predict or model systems that have not been designed, built, or deployed.

9.3

CMAS End-to-End Reliability

The CMSAAC recommends that CMAS system reliability from alert initiation to the transmission of the
CMAM over the CMSP selected delivery technology meet telecom standards for highly reliable systems.
In order to achieve, a feasible and practical level of CMAS reliability on an end-to-end basis:
•

The CMSPs will process CMAS alerts on a best effort

•

The CMAS alert message may be retransmitted according to CMSP policies and the capabilities of
the CMSP selected delivery technology.

Even though many components and elements of the end to end CMAS solution have high reliability, the
over-all reliability of CMAS is unpredictable for the following reasons:
•

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. For example, it can not be predicted which and how many cell sites will remain
operational after a disaster.

•

The subscriber may currently be in a location that does not have any RF signal.

•

The subscriber’s mobile device may not have any remaining power.
71

Commercial Mobile Alert Service Architecture and Requirements

9.4

Message Logging

2
3
4
5

The CMSAAC recommends that the logs on the Alert Gateway be used to identify messages received by or
rejected by the CMSP Gateway. These logs will be accessible by the alert originators and by the CMSPs.
These logs will be the only required audit methods for the determination of which CMAS messages were
sent to the CMSPs.

6
7
8
9

The CMSAAC further recommends that, upon receipt of an alert, the CMSP Gateway will respond back to
the Alert Gateway with an acknowledgment that the alert message was received or rejected. Message
logging on the CMSP Gateway is a function of the system performance part of the Commercial Mobile
CMSP's business, and will not be an audit trail.

10
11

The CMSAAC recommends that there be no requirements for the CMSP to retain logs for any period of
time.

12
13

9.4.1

Alert Gateway Logging

14
15
16
17
18
19

The CMSAAC makes the following recommendations regarding Alert Gateway logging:
1.

The Alert Gateway will maintain a log of messages with time-stamps that verify when messages are
received from the Alert Aggregator and when the messages are acknowledged or rejected by the
CMSP Gateway. The log for rejected messages will include error codes for rejection as specified in
Section 10.4.6 below.

The Alert Gateway will maintain an online log of active and cancelled alert messages for 90 days.

The Alert Gateway will maintain archived logs for a minimum of 36 months.

22
23

The Alert Gateway will provide CMSPs access to online messaging logs and archived logs for testing
and trouble shooting purposes.

24
25

The Alert Gateway will generate monthly system and performance statistics reports based on CMA
alerting category, alerting originator, alerting area and other alerting attributes.

26
27
28

The Alert Gateway will provide the capability for a CMSP to temporarily disable the transmission of
all CMAMs to the CMSP Gateway. This event will be captured in the log file. Cancellation of the
event should be noted in the log file as well.

29
30

9.5

CMAS Testing

31
32
33
34
35

End-to-end testing of the CMAS is defined to be testing from the Alert Initiator to the CMSP Gateway.
This testing will verify the A, B, and C reference points, as well as the function of the Alert Aggregator,
Alert Gateway, and CMSP Gateway. It is undesirable to send test messages over the CMSP infrastructure
to the mobile devices as these messages could cause considerable confusion to the end user, as well as
utilizing CMSP network resources.

36
37
38
39
40
41

Using real event codes for testing purposes poses the risk of unintentionally alarming and confusing
recipients. For this reason, and to insure that a test message does not propagate to the CMSP subscriber
base, the CMSAAC recommends that all end-to-end testing be indicated using the CAP status element with
a value of “test”, which shall be mapped to a test message over Reference Point C. Upon receipt of a test
message, the CMSP Gateway will respond with an acknowledgment of receipt of the message and log
receipt of the message according to CMSP policy.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

The CMSAAC recommends that the CMSP Gateway support receiving a test message from the Alert
Gateway for testing Reference Point C. This test message shall not be delivered to the CMSP Infrastructure
nor broadcast to subscribers.

4
5
6

The CMSAAC recommends that the CMSP Gateway support the receipt and processing of Alert Gateway
keep-alive test messages periodically. The frequency shall be configurable based on policy to be
determined by the authorized government entity and the CMSPs.

7
8

The CMSAAC recommends that the keep-alive test messages not be sent if there are real messages to be
sent.

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

9.5.1

General CMAS Testing Recommendations

An important part of a successful CMAS will be the ability to effectively test and troubleshoot the various
components and interfaces.
The CMSAAC recommends that this test and troubleshooting capability be integrated into the architecture
and protocol of the CMAS up front, to maximize effectiveness.
The CMSAAC recommends the following primary aspects of CMAS Testing and Troubleshooting
capability to allow thorough testing and troubleshooting of the end-to-end CMAS without wearying the
public:
1.

Provision for testing of the CMAS, including the delivery mechanisms, without requiring all
subscribers to see a test message.
a.

This might be accomplished by providing signaling in the application layer which
indicates a test message – which would not be displayed by ‘normal terminals’, but could
be displayed by ‘test terminals’. CMSPs could configure which devices were ‘test
terminals’.

Provide the ability to send test messages to a single CMSP/network without impact to
other CMSPs.

Provide the ability to test the CMAS up to the CMSP Gateway without impacting the
CMSP infrastructure.

Provide CMSP access to the CMAM logs from the Alert Gateway.

Messages used for testing purposes shall be clearly differented from messages for actual events

9.5.2

Alert Gateway Testing

The CMSAAC recommends that the Alert Gateway support several types of testing:

Functional testing for the C interface (not expected to be sent to the subscribers)

Connection testing for new CMSP

The CMSAAC further recommends the following requirements for Alert Gateway testing:

45
46
47

The Alert Gateway will support initiating a test message for each service profile implemented for
Reference Point C upon request by a particular CMSP. The test message will only be sent to a specific
CMSP Gateway. The message will not be broadcast to subscribers.
73

Commercial Mobile Alert Service Architecture and Requirements

1
2

The Alert Gateway will support initiating a test message for each service profile implemented for
Reference Point C for all CMSP Gateways. The message will not be broadcast to subscribers.

3
4
5

The Alert Gateway will support keep-alive test messages periodically over the C interface. The
frequency will be configurable based on policy to be determined by the authorized government entity
and the CMSPs. The keep-alive test messages will not be sent if there are real messages to be sent.

All test messages for the C interface will be clearly marked and identified as test messages.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

10 Interface Protocols for CMAS Alerts
The following two interfaces are applicable for the support of CMAS alerts in the CMSP networks:

•

Alert Gateway – CMSP Interface which is Reference Point C

•

CMSP – Mobile Device Interface for CMAS alert content which is Reference Point E

6
7
8
9
10
11
12
13

Both of these interfaces are defined in this section.

10.1

Reference Point A Protocol

The CMSAAC recommends that Reference Point A interface requirements consist of the following:
1.

The message sent to the Alert Aggregator must consist of one of the following:
a. A valid CAP 1.1 message with all mandatory elements.
• Message ID

•

Sender ID

•

Sent Date/Time

•

Message Status

•

Message Type

•

Scope

•

Event Category

•

Urgency

•

Severity

•

Certainty

•

Resource description

24
25

•

Area Description – A FIPS geo-code, a polygon or circle (WGS-84 format) will
be used to support the area description.

26
27
28
29
30
31

The Alert Aggregator will provide a mechanism to validate the identity of the individual sending
the message to allow non-repudiation.

The implementer of the alert aggregator will provide a documented, non-proprietary, specification
for transport that will support appropriate security and reliability.

10.2

33
34
35
36
37

Reference Point B Protocol

The CMSAAC recommends that Reference Point B interface requirements consist of the following:
1.

The implementer of the Alert Gateway will provide a documented non-proprietary specification for the
B interface which will support appropriate security and reliability.

Commercial Mobile Alert Service Architecture and Requirements

10.3

10.3.1

3
4
5

Alert Gateway Interfaces & Mapping Requirements
Alert Gateway Interface Requirements

The CMSAAC recommends the following requirements for the Alert Gateway interfaces:
1.

The Alert Gateway will support an open, non-proprietary interface to the Alert Aggregator (e.g. IP).

6
7

The Alert Gateway will initially support CAP v1.1 as the application layer protocol for communicating
with the Alert Aggregator.

8
9

The Alert Gateway will uniquely identify each CMSP Gateway identified by a unique IP address or
domain name.

The Alert Gateway will support the “C” interface protocol as defined in Section 10.4 below.

The Alert Gateway will support all CMAM formats that can be delivered to CMSP Gateway.

12
13

The Alert Gateway will support the common service profile formats as referred to in Section 6 above
for text, audio, video and multimedia transmission of alert messages to the CMSP Gateways.

14
15

The Alert Gateway will support receiving acknowledgement from the CMSP Gateway that the CMAM
has been received or rejected by the CMSP Gateway.

16
17
18

If any mandatory parameter/attribute is not included in the CAP message sent over the B interface, the
Alert Gateway will use a default parameter value if available, or reject the CAP message if a default
parameter value is not available.

19
20

10.3.2

Alert Gateway Interface Mapping Requirements

21
22

The Alert Gateway will map the CMAMs received in CAP format into the CMAC format supported by the
CMSP Gateway.

23
24

If eventCode = “EAN”, the CMAM will be handled as a Presidential Alert. The Alert Gateway will
not forward messages with eventCode = “EAT” or “NIC” to the CMSP Gateway.

25
26

The Alert Gateway will deliver CMAMs using the same language as issued by the alert originator and
will not do language translation as a gateway function.

27
28

Each CMAM will only include one language. The CMA issued in multiple languages will be issued by
separate messages.

29
30
31

All CMAM alert, update & cancellation messages will come only from the alert originators, including
Presidential alert. The Alert Gateway will pass these messages to the CMSP Gateway. The Alert
Gateway is not required to generate alerts, alert updates and/or cancellations.

The Alert Gateway will not alter the content of text alert messages, with the exception of

If CAP expires is not available, the default parameter value of one hour shall be used.

34
35
36

Constructing the text alert message using CAP elements such as category, eventCode and
responseType. The algorithm for constructing the text alert message is described in Section 5.3
above.

Commercial Mobile Alert Service Architecture and Requirements

1
2

For Presidential Alert, the Alert Gateway will use the following CAP elements to construct the
message:

3
4

Use CAP parameter (with valueName = CMAMtext), if available and less than the
maximum CMA message length limit. If not, then

5
6

Use Alert Gateway generated automatic text: “The President has issued an
emergency alert. Check local media for more details.”

8
9
10

For AMBER Alert, the Alert Gateway will use the following CAP elements to construct the message:
a.

Use CAP parameter (with valueName = CMAMtext), if available and less than the
maximum CMA message length limit. If not, the Alert Gateway will reject the
message.

11
12

For alerts other than the Presidential Alert or AMBER Alert, the Alert Gateway will support freeformat text generation or automatic text generation.

13
14
15
16

For free-format text generation, the Alert Gateway will use the CAP parameter (with valueName =
CMAMtext) to construct the message. If the CAP parameter (with valueName = CMAMtext) is not
available or exceeds the maximum CMA message length limit, the Alert Gateway will reject the
message.

17
18

10. For automatic text generation, the Alert Gateway will support the following rules to construct the
message:

19
20
21
22

What’s happening: The Alert Gateway will use the expanded text as defined in
Table 5.1 for the CAP eventCode element if available. If eventCode is not provided,
the Alert Gateway will use the expanded text as defined in Table 5.1 for the CAP
category element.

Area Affected: The Alert Gateway will use the phrase “in this area”.

24
25
26

Recommended action: The Alert Gateway will use the CAP responseType element if
available. If responseType is not provided, the Alert Gateway will not include this
information.

Area Affected: The Alert Gateway will use the phrase “in this area”.

28
29
30
31
32
33

Expiration time with time zone: The Alert Gateway will translate the time according
to Table 5.1 for the CAP expires element if provided. The Alert Gateway will use the
time zone provided in the CAP expires element or may use the time zone in the
affected area. If not provided, the Alert Gateway will use one hour from the current
time as a default. If the affected area has more than one time zone, the Alert Gateway
will use one of the time zones.

34
35
36
37
38

Sending Agency: The Alert Gateway will translate it according to Table 5.1 for the
CAP sender element. The translated sending agency should not exceed the maximum
length of 12 characters in order to fit into the maximum CMA message length limit.
The translated sending agency will be truncated to 12 characters if it causes the
constructed message to exceed the maximum CMA message length limit.

39
40

11. If the CAP message received by the Alert Gateway is not formatted correctly, the Gateway will reject
the message and inform the Alert Originator.

Commercial Mobile Alert Service Architecture and Requirements

1
2
3

12. If a CAP message contains multiple INFO blocks with the same headline but different area elements,
the Alert Gateway will collapse it into a single CMAM with a single INFO block and multiple area
elements before sending it to the CMSP Gateway.

4
5
6

13. If a CAP message contains multiple INFO blocks with the different headlines, the Alert Gateway will
create separate CMAM with each INFO block. The Alert Gateway will process the INFO blocks in the
order contained in the CAP message.

14. The Alert Gateway will not do translations of the character sets.

8
9

15. The Geo-mapping of targeted area (cell sites) will be the responsibility of CMSPs and not a function of
the Alert Gateway.

10
11

16. The Alert Gateway will provide the geo-targeting information over Reference Point C in accordance
with the CMSP profile stored within the Alert Gateway.

17. The Alert Gateway will provide Geocode as specified in Section 10.4 below to the CMSP Gateway.

13
14

18. The Alert Gateway will translate latitude/longitude coordinates into appropriate State or County
Geocode if no State or County Geocode is provided by alert originator.

15
16

19. The Alert Gateway will not be required to translate State or County Geocode into latitude/longitude
coordinates.

17
18

20. The Alert Gateway will specify an agreed upon maximum number of latitude/longitude coordinates per
polygon to be sent to the CMSP Gateway.

19
20

21. If Geocode, polygon or circle is not provided for a Presidential alert, the Alert Gateway will use
“Nation wide” by default.

21
22

22. If Geocode, polygon or circle is not provided for any non-presidential alert or update, the Alert
Gateway will reject the message and return an error to the alert originator.

23
24

23. For audio, video and multi-media CMAMs, if the CAP message includes the associated files, the Alert
Gateway will

25
26

Re-format, if necessary, the associated files into standardized format as specified in the
associated service profile (See Section 6 above).

Store the associated files on the Alert Gateway to be retrieved by the CMSP Gateways.

28
29

Send the message with proper URL so that CMSP Gateways can retrieve the files if they so
choose.

30
31

24. For audio, video and multi-media CMAMs, if the CAP message includes only the URL but not the
associated files, the Alert Gateway will

Retrieve the associated files from the URL in the CAP message

33
34

Re-format, if necessary, the associated files into standardized format as specified in the
associated service profile (See Section 6 above).

Store the associated files on the Alert Gateway to be retrieved by the CMSP Gateway.

36
37

Send the message with proper URL so that CMSP Gateway can retrieve the files if they so
choose.
78

Commercial Mobile Alert Service Architecture and Requirements

1
2
3
4

25. The Alert Gateway, via Reference Point C, will always provide the CMSP Gateway, the
CMAC_geocode as defined in Section 10.4 below. Additionally, if available, the Alert Gateway will
provide one or more of the following parameters to identify the alert area: CMAC_polygon,
CMAC_circle or CMAC_gnis format.

5
6
7
8

26. The Alert Gateway will be responsible to generate the CMAC geocode(s) corresponding to the alert
area from the CAP “area” element. The CMAC geocode(s) corresponding to the alert area will be
generated from either the area described by the polygon or circle, conversion of the SAME code or ZIP
code for the alert area, or using the FIPS value if specified in the original CAP alert message.

9
10
11

27. If the original CAP message does not contain a polygon, circle, or geocode, the Alert Gateway will
reject the message unless the message originator was the President, in which case the alert area will be
assumed Nationwide in the absence of the area information.

12
13
14
15
16

28. CAP will be the protocol used on the “B” interface to carry the CMAM into the Alert Gateway. Not all
the elements and values allowed by CAP are useful for CMAMs. Also some elements are optional in
CAP but required by CMAMs. The Alert Gateway will apply the following mapping and filtering rules
for all the messages received via the “B” interface as shown in Table 10-1. The following is a
description of the column shown in Table 10-1:

Column 1: Lists the CAP element.

Column 2: Lists the code values applicable to CMAMs.

19
20
21
22
23
24
25

Column 3: Lists the filtering and mapping rules to be used by the Alert Gateway. “Pass” means
the element and code value will be passed from the “B” interface to the “C” interface. “Mapped”
means the CAP element and code value will be mapped into the appropriate CMAC attribute.
“Reject” means the Alert Gateway will reject the CAP message received from the “B” interface
and no message will be sent over the “C” interface. “Ignored” means the CAP element is not
applicable to CMAM and will be ignored by the Alert Gateway. “Generated” means the Alert
Gateway will generate the appropriate CMAC elements and attributes.

26
27
28

Column 4: Lists the corresponding “C” interface CMAC elements as defined in Section 10.4
below.
Table 10-1

Parameter mapping from “B” Interface CAP message in to “C” Interface CMAC message

CAP
Element

(CMA)
Permitted
Values

Alert Gateway
Filtering Rules

CMAC Element

N/A

Generated by the Alert Gateway

CMAC protocol version

N/A

Generated by the Alert Gateway

CMAC sending Alert Gateway id

Ignored

N/A

identifier
(free format)

Mapped from the free format into
a 2 octet binary number

CMAC_message_identifier
(2 octet binary number)

sender

Pass

CMAC_sender

sent

Mapped into UTC format

CMAC_sent_date_time

Pass with permitted values;
Reject message with “Draft”

CMAC_status

alert

status

N/A

“Actual”
“Exercise”
“System”
“Test”

Commercial Mobile Alert Service Architecture and Requirements

msgType

“Alert”
“Update”
“Cancel”
“Error”

Pass with permitted values;
Reject message with “Ack”

source

N/A

Ignored

scope

“Public”

Reject message if “Public” is not
in field.

N/A

restriction

Reject message if this element is
included

N/A

addresses

Reject message if this element is
included

N/A

code

Ignored

N/A

note

Pass

CMAC_cancel_error_node

references

Mapped from the free format into
a 2 octet binary number

CMAC_referenced_message_identifier
(2-octet binary number)

Ignored

N/A

Generated by the Alert Gateway

CMAC_original_cap_alert_uri

info

Ignored

language

Pass

CMAC_text_language

File Type	application/pdf
File Title	Before the
Author	Gregory Cooke
File Modified	2007-12-19
File Created	2007-12-19