[Federal Register Volume 73, Number 2 (Thursday, January 3, 2008)]
[Proposed Rules]
[Pages 546-607]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: E7-24876]



[[Page 545]]

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

Part II





Federal Communications Commission





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



47 CFR Chapter I



Commercial Mobile Alert System; Proposed Rule

  Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / 
Proposed Rules  

[[Page 546]]


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

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Chapter I

[PSHSB Docket No. 07-287; FCC 07-214]


Commercial Mobile Alert System

AGENCY: Federal Communications Commission.

ACTION: Notice of Proposed Rulemaking.

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

SUMMARY: By this Notice of Proposed Rulemaking, the Federal 
Communications Commission (Commission or FCC) initiates a comprehensive 
rulemaking to establish a Commercial Mobile Alert System (CMAS). In 
particular, the Commission seeks comment on the recommendations of the 
Commercial Mobile Services Alert Advisory Committee (CMSAAC). These 
recommendations are attached as Appendix A. The Commission convened the 
CMSAAC in compliance with the Warning Alert and Response Network (WARN) 
Act, which requires that the FCC adopt technical standards, protocols, 
procedures, and other technical requirements for the CMAS based on the 
recommendations of the CMSAAC. The purpose of this rulemaking is to 
create a mechanism under which CMS providers may elect to transmit 
emergency alerts to the public. The Commission has initiated this 
proceeding to comply with the Warning Alert and Response Network (WARN) 
Act and to satisfy the Commission's mandate to promote the safety of 
life and property through the use of wire and radio communication.

DATES: Comments are due on or before February 4, 2008, and reply 
comments are due on or before February 19, 2008. Written comments on 
the Paperwork Reduction Act proposed information collection requirement 
must be submitted by the public, Office of Management and Budget (OMB), 
and other interested parties on or before March 3, 2008.

ADDRESSES: Send comments and reply comments to the Office of the 
Secretary, Federal Communications Commission, 445 12th Street, SW., 
Room TW-A325, Washington, DC 20554. You may submit comments, identified 
by PSHSB Docket No. 07-287, by any of the following methods:
     Federal eRulemaking Portal: http://www.regulations.gov/. 
Follow the instructions for submitting comments.
     Federal Communications Commission's Web site: http://www.fcc.gov/cgb/ecfs/. Follow the instructions for submitting comments.
     People with Disabilities: Contact the FCC to request 
reasonable accommodations (accessible format documents, sign language 
interpreters, CART, etc.) by e-mail; [email protected] or phone: 202-418-
0530 or TTY: 202-418-0432.
    In addition to filing with the Secretary, a copy of any comments on 
the Paperwork Reduction Act information collection requirement 
contained herein should be submitted to the Federal Communications 
Commission via e-mail to [email protected] and to Nicholas A. Fraser, Office 
of Management and Budget, via e-mail to [email protected] or via fax at 202-395-5167.

FOR FURTHER INFORMATION CONTACT: Lisa M. Fowlkes, Deputy Bureau Chief, 
PSHSB, at (202) 418-7450 or Jeffery Goldthorp, Chief, Communications 
Services Analysis Division, PSHSB at (202) 418-1096. For additional 
information concerning the Paperwork Reduction Act information 
collection requirement contained in this document, send an e-mail to 
[email protected] or contact Jerry Cowden at (202) 418-0447.

SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Notice 
of Proposed Rulemaking (NPRM) in PSHSB Docket No. 07-287, FCC 07-214, 
adopted December 14, 2007, and released December 14, 2007. The complete 
text of this document is available for inspection and copying during 
normal business hours in the FCC Reference Information Center, Portals 
II, 445 12th Street, SW., Room CY-A257, Washington, DC 20554. This 
document may also be purchased from the Commission's duplicating 
contractor Best Copy and Printing, Inc., Portals II, 445 12th Street, 
SW., Room CY-B402, Washington, DC 20554, telephone (800) 378-3160 or 
(202) 488-5300, facsimile (202) 488-5563, or via e-mail at 
[email protected]. It is also available on the Commission's Web site at 
http://www.fcc.gov.
    This document contains a proposed information collection 
requirement. The Commission, as part of its continuing effort to reduce 
paperwork burdens, invites the general public and the OMB to comment on 
the proposed information collection requirement contained in this 
document, as required by the Paperwork Reduction Act of 1995, Public 
Law 104-13. Public and agency comments are due March 3, 2008.
    Comments should address: (a) Whether the proposed collection of 
information is necessary for the proper performance of the functions of 
the Commission, including whether the information shall have practical 
utility; (b) the accuracy of the Commission's burden estimates; (c) 
ways to enhance the quality, utility, and clarity of the information 
collected; and (d) ways to minimize the burden of the collection of 
information on the respondents, including the use of automated 
collection techniques or other forms of information technology. 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 it might ``further reduce the information collection burden for 
small business concerns with fewer than 25 employees.''
    OMB Control Number: None.
    Title: Election Whether To Participate in the Commercial Mobile 
Alert System.
    Form No.: N/A.
    Type of Review: New Collection.
    Respondents: Businesses or other for-profit.
    Number of Respondents: 1,253.
    Time per Response: 6 minutes.
    Frequency of Response: One-time.
    Obligation to Respond: Mandatory.
    Total Annual Burden: 125.3 hours.
    Total Annual Costs: $0.
    Privacy Act Impact Assessment: N/A.
    Nature and Extent of Confidentiality: Not applicable.
    Needs and Uses: Section 602(b)(2)(A) of the WARN Act requires each 
Commercial Mobile Service (CMS) provider to notify the Commission, 
within 30 days of the Commission's release of the order adopting CMAS 
technical requirements and protocols, whether it intends to participate 
in the CMAS. The information collected will be the CMS provider's 
contact information and its election, i.e., a ``yes'' or ``no,'' on 
whether it intends to provide commercial mobile service alerts. The 
Commission will use the information collected to meet its statutory 
requirement under the WARN Act to accept licensees' election filings 
and to establish an effective CMAS that will provide the public with 
effective mobile alerts in a manner that imposes minimal regulatory 
burdens on affected entities.

Synopsis of the Notice of Proposed Rulemaking

    1. Background. On October 13, 2006, the President signed the 
Security and Accountability For Every Port (SAFE Port) Act into law. 
Title VI of the SAFE Port Act, the WARN Act, establishes a process for 
CMS providers to elect to transmit emergency alerts to their 
subscribers. The WARN Act requires that the Commission engage in a 
series of activities to accomplish that goal. Among these activities 
was the

[[Page 547]]

requirement that by December 12, 2006, the Commission 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. The Commission formed the Commercial Mobile Service 
Alert Advisory Committee (CMSAAC), which had its first meeting on this 
date. 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. The CMSAAC 
submitted its report on this date. Within 180 days of receipt of the 
CMSAAC's recommendations, the Commission must complete a proceeding to 
adopt technical standards, protocols, procedures and technical 
requirements based on recommendations submitted by the CMSAAC. A copy 
of the CMSAAC recommendations is attached to this NPRM.
    2. Introduction. 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 requirement that the Commission enable 
commercial mobile service alerting capability for providers that elect 
to transmit emergency alerts. 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. 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 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 
seek comment on questions pertaining to all of these statutory 
requirements. 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).
    4. 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.
    5. 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. As we noted in our 2005 EAS Further Notice of 
Proposed Rulemaking, 70 FR 7102-01, wireless services are becoming 
equal to television and radio as an avenue to reach the American public 
quickly and efficiently. As of June 2007, approximately 243 million 
Americans subscribed to wireless services. Wireless service has 
progressed beyond voice communications and now provides subscribers 
with access to a wide range of information critical to their personal 
and business affairs. In times of emergency, Americans 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.
    6. On October 13, 2006, the President signed the Security and 
Accountability For Every Port (SAFE Port) Act into law. Title VI of the 
SAFE Port Act, the WARN Act, establishes a process for CMS providers to 
elect to transmit emergency alerts to their subscribers. The WARN Act 
requires that 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. We formed the 
Commercial Mobile Service Alert Advisory Committee (CMSAAC), which had 
its first meeting on this date.
     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 under which NOAA may issue 
grants to provide for outdoor alerting technologies. We issued a 
Declaratory Ruling addressing this issue on April 11, 2007.
     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. 
The CMSAAC submitted its report on this date. The CMSAAC 
recommendations are attached at Appendix B.
     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.
     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 
providers that

[[Page 548]]

have elected to transmit emergency alerts.
     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.
     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.

WARN Act Section 602(a)--Technical Requirements

    7. 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, 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. 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. 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.
    8. 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.
    9. Available Transport Technologies. 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-to-multipoint 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. 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?
    10. 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?
    11. 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? Comments should include a discussion concerning the broad range 
of devices intended to utilize the CMAS and potential impact on the 
subscriber service experience.
    12. 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.
    13. Federal Government's Role. 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)) 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? 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).
    14. 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

[[Page 549]]

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?
    15. Use of the Common Alerting Protocol (CAP). 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. We also seek 
comment about the use of CAP as a general, system-wide CMAS interface. 
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. 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.
    16. Alert Formatting, Classes, and Content Issues. 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. Commenters should provide detailed technical 
explanation in support of their positions and explain the relationship 
between ``payload'' and ``displayable message size'' as referenced in 
the CMSAAC's recommendations.
    17. 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. 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?
    18. 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.
    19. 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. 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?
    20. 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. We 
seek comment on this recommendation. We also seek comment on whether 
Presidential and Amber alerts can be structured to use automatic text.
    21. 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? 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 network congestion if subscribers were directed to a specific 
number (such as a ``311'' number in New York City) or URL?
    22. Geographically Targeted Commercial Mobile Alerts. 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.'' 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.'' 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.
    23. 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.'' 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.'' We seek comment on these and the other recommendations 
raised in section 5.4 of the CMSAAC's recommendations.
    24. CMAS for Individuals With Disabilities and the Elderly. 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. The CMSAAC submitted 
recommendations addressing the needs of users, including individuals 
with disabilities and the elderly, and we seek comment on these 
recommendations. 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? Further, the CMSAAC recommended that 
the alert initiator use clear and simple

[[Page 550]]

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?
    25. Transmission of CMAS Alerts in Languages Other Than English. 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. CMSAAC also asserted that multilingual (and geo-targeted) 
alerting would raise latency (alert delay) concerns. How would 
requirements for multi-language alerts affect the generation and 
distribution of messages on a local, state and national level?

WARN Act Section 602(b)--CMAS Election Rulemaking

    26. 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.
    27. Notice at Point of Sale. 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.'' 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.''
    28. 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. 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. Are there 
others that should be included?
    29. 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. We seek comment on this text. Does it satisfy the statute?
    30. 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?
    31. Notifications to Existing Subscribers. 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 emergency alerts to notify its existing 
subscribers of its election.'' 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? 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? Should service providers 
be required to maintain a record of subscribers who have acknowledged 
receipt of the service provider's notification?
    32. Related Filings and Other Requirements. Sections 602(b)(2)(A), 
(B), (D) and (E) establish certain

[[Page 551]]

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.'' 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.'' 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. 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.'' 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 subparagraph (A).'' 
The CMSAAC proposed a timeline for election based on its interpretation 
of the WARN Act. We seek comment on this interpretation and timeline. 
Commenters with a different interpretation should provide detailed 
alternatives.
    33. 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?
    34. 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?
    35. 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, 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?
    36. 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.'' We seek 
comment on the procedures 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?
    37. 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.'' The CMSAAC recommended that the CMS 
providers should offer their subscribers a simple opt-out process. 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. 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 on 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

[[Page 552]]

device features. To what extent is a uniform methodology for disabling 
this feature necessary? Are there more classes of alerts that should be 
considered?
    38. 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.'' 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. We 
seek comment on this recommendation.
    39. 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.'' 
Does this provision completely preclude a participating service 
provider's ability to recover costs associated with the provision of 
alerts? 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?

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

    40. 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 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?
    41. How will this DTV-based system interface with the CMAS? How 
will this requirement regarding the geo-targeting of CMAMs fit 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?

WARN Act Section 602(f)--Testing

    42. 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 
ensure 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 an end-to-end basis should be 
implemented. We seek comment on these proposed procedures. Do they 
satisfy the 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. 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?

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

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

Initial Regulatory Flexibility Analysis

    44. As required by the Regulatory Flexibility Act of 1980, as 
amended (RFA), 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

[[Page 553]]

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). In addition, the NPRM and IRFA (or 
summaries thereof) will be published in the Federal Register.
    45. Need for, and Objectives of, the Proposed Rules. With the NPRM, 
the Federal Communications Commission (Commission), as required by the 
Warning Alert and Response Network (WARN) Act, 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.
    46. 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 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. 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).
    47. Legal Basis. 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.

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

    48. The RFA directs agencies to provide a description of, and, 
where feasible, an estimate of, the number of small entities that may 
be affected by the rules adopted herein. The RFA generally defines the 
term ``small entity'' as having the same meaning as the terms ``small 
business,'' ``small organization,'' and ``small governmental 
jurisdiction.'' In addition, the term ``small business'' has the same 
meaning as the term ``small business concern'' under the Small Business 
Act. A ``small business concern'' is one which: (1) is independently 
owned and operated; (2) is not dominant in its field of operation; and 
(3) satisfies any additional criteria established by the Small Business 
Administration (SBA).
    49. Small Businesses. Nationwide, there are a total of 
approximately 22.4 million small businesses, according to SBA data.
    50. Small Organizations. Nationwide, there are approximately 1.6 
million small organizations.
    51. 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.
    52. Wireless Telecommunications Carriers (except Satellite). Since 
2007, the SBA has recognized wireless firms within this new, broad, 
economic census category. Prior to that time, the SBA had developed a 
small business size standard for wireless firms within the now-
superseded census categories of ``Paging'' and ``Cellular and Other 
Wireless Telecommunications.'' Under the present and prior categories, 
the SBA has deemed a wireless business to be small if it has 1,500 or 
fewer employees. Because Census Bureau data are not yet available for 
the new category, we will estimate small business prevalence using the 
prior categories and associated data. For the first category of Paging, 
data for 2002 show that there were 807 firms that operated for the 
entire year. Of this total, 804 firms had employment of 999 or fewer 
employees, and three firms had employment of 1,000 employees or more. 
For the second category of Cellular and Other Wireless 
Telecommunications, data for 2002 show that there were 1,397 firms that 
operated for the entire year. Of this total, 1,378 firms had employment 
of 999 or fewer employees, and 19 firms had employment of 1,000 
employees or more. Thus, using the prior categories and the available 
data, we estimate that the majority of wireless firms can be considered 
small.
    53. Cellular Service. As noted, the SBA has developed a small 
business size standard for small businesses in the category ``Wireless 
Telecommunications Carriers (except satellite).'' Under that SBA 
category, a business is small if it has 1,500 or fewer employees. Since 
2007, the SBA has recognized wireless firms within this new, broad, 
economic census category. Prior to that time, the SBA had developed a 
small business size standard for wireless firms within the now-
superseded census categories of ``Paging'' and ``Cellular and Other 
Wireless Telecommunications.'' 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.
    54. For the first category of Paging, data for 2002 show that there 
were 807 firms that operated for the entire year. Of this total, 804 
firms had employment of 999 or fewer employees, and three firms had 
employment of 1,000 employees or more. For the second category of 
Cellular and Other Wireless Telecommunications, data for 2002 show that 
there were 1,397 firms that operated for the entire year. Of this 
total, 1,378 firms had employment of 999 or fewer employees, and 19 
firms had employment of 1,000 employees or more. Thus, using the prior 
categories and the available data, we estimate that the majority of 
wireless firms can be considered small.
    55. 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 
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.
    56. Broadband Personal Communications Service. The broadband 
Personal Communications

[[Page 554]]

Service (PCS) spectrum is divided into six frequency blocks designated 
A through F, and the Commission has held auctions for each block. The 
Commission has created a small business size standard for Blocks C and 
F as an entity that has average gross revenues of less than $40 million 
in the three previous calendar years. For Block F, an additional small 
business size standard for ``very small business'' was added and is 
defined as an entity that, together with its affiliates, has average 
gross revenues of not more than $15 million for the preceding three 
calendar years. These small business size standards, in the context of 
broadband PCS auctions, have been approved by the SBA. No small 
businesses within the SBA-approved small business size standards bid 
successfully for licenses in Blocks A and B. There were 90 winning 
bidders that qualified as small entities in the C Block auctions. A 
total of 93 ``small'' and ``very small'' business bidders won 
approximately 40 percent of the 1,479 licenses for Blocks D, E, and F. 
On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block 
licenses; there were 113 small business winning bidders. On January 26, 
2001, the Commission completed the auction of 422 C and F PCS licenses 
in Auction 35. Of the 35 winning bidders in this auction, 29 qualified 
as ``small'' or ``very small'' businesses. Subsequent events concerning 
Auction 35, including judicial and agency determinations, resulted in a 
total of 163 C and F Block licenses being available for grant.
    57. Narrowband Personal Communications Service. The Commission held 
an auction for Narrowband Personal Communications Service (PCS) 
licenses that commenced on July 25, 1994, and closed on July 29, 1994. 
A second commenced on October 26, 1994 and closed on November 8, 1994. 
For purposes of the first two Narrowband PCS auctions, ``small 
businesses'' were entities with average gross revenues for the prior 
three calendar years of $40 million or less. Through these auctions, 
the Commission awarded a total of forty-one licenses, 11 of which were 
obtained by four small businesses. To ensure meaningful participation 
by small business entities in future auctions, the Commission adopted a 
two-tiered small business size standard in the Narrowband PCS Second 
Report and Order. A ``small business'' is an entity that, together with 
affiliates and controlling interests, has average gross revenues for 
the three preceding years of not more than $40 million. A ``very small 
business'' is an entity that, together with affiliates and controlling 
interests, has average gross revenues for the three preceding years of 
not more than $15 million. The SBA has approved these small business 
size standards. A third auction commenced on October 3, 2001 and closed 
on October 16, 2001. Here, five bidders won 317 (MTA and nationwide) 
licenses. Three of these claimed status as a small or very small entity 
and won 311 licenses.
    58. Wireless Communications Services. This service can be used for 
fixed, mobile, radiolocation, and digital audio broadcasting satellite 
uses in the 2305-2320 MHz and 2345-2360 MHz bands. The Commission 
defined ``small business'' for the wireless communications services 
(WCS) auction as an entity with average gross revenues of $40 million 
for each of the three preceding years, and a ``very small business'' as 
an entity with average gross revenues of $15 million for each of the 
three preceding years. The SBA has approved these definitions. The 
Commission auctioned geographic area licenses in the WCS service. In 
the auction, which commenced on April 15, 1997 and closed on April 25, 
1997, there were seven bidders that won 31 licenses that qualified as 
very small business entities, and one bidder that won one license that 
qualified as a small business entity.
    59. 700 MHz Guard Bands Licenses. In the 700 MHz Guard Bands Order, 
the Commission adopted size standards for ``small businesses'' and 
``very small businesses'' for purposes of determining their eligibility 
for special provisions such as bidding credits and installment 
payments. A small business in this service is an entity that, together 
with its affiliates and controlling principals, has average gross 
revenues not exceeding $40 million for the preceding three years. 
Additionally, a ``very small business'' is an entity that, together 
with its affiliates and controlling principals, has average gross 
revenues that are not more than $15 million for the preceding three 
years. SBA approval of these definitions is not required. An auction of 
52 Major Economic Area (MEA) licenses for each of two spectrum blocks 
commenced on September 6, 2000, and closed on September 21, 2000. Of 
the 104 licenses auctioned, 96 licenses were sold to nine bidders. Five 
of these bidders were small businesses that won a total of 26 licenses. 
A second auction of remaining 700 MHz Guard Bands licenses commenced on 
February 13, 2001, and closed on February 21, 2001. All eight of the 
licenses auctioned were sold to three bidders. One of these bidders was 
a small business that won a total of two licenses. Subsequently, in the 
700 MHz Second Report and Order, the Commission reorganized the 
licenses pursuant to an agreement among most of the licensees, 
resulting in a spectral relocation of the first set of paired spectrum 
block licenses, and an elimination of the second set of paired spectrum 
block licenses (many of which were already vacant, reclaimed by the 
Commission from Nextel). A single licensee that did not participate in 
the agreement was grandfathered in the initial spectral location for 
its two licenses in the second set of paired spectrum blocks. 
Accordingly, at this time there are 54 licenses in the 700 MHz Guard 
Bands.
    60. 700 MHz Band Commercial Licenses. There is 80 megahertz of non-
Guard Band spectrum in the 700 MHz Band that is designated for 
commercial use: 698-757, 758-763, 776-787, and 788-793 MHz Bands. With 
one exception, the Commission adopted criteria for defining two groups 
of small businesses for purposes of determining their eligibility for 
bidding credits at auction. These two categories are: (1) ``small 
business,'' which is defined as an entity that has attributed average 
annual gross revenues that do not exceed $15 million during the 
preceding three years; and (2) ``very small business,'' which is 
defined as an entity with attributed average annual gross revenues that 
do not exceed $40 million for the preceding three years. In Block C of 
the Lower 700 MHz Band (710-716 MHz and 740-746 MHz), which was 
licensed on the basis of 734 Cellular Market Areas, the Commission 
adopted a third criterion for determining eligibility for bidding 
credits: an ``entrepreneur,'' which is defined as an entity that, 
together with its affiliates and controlling principals, has average 
gross revenues that are not more than $3 million for the preceding 
three years. The SBA has approved these small size standards.
    61. An auction of 740 licenses for Blocks C (710-716 MHz and 740-
746 MHz) and D (716-722 MHz) of the Lower 700 MHz Band commenced on 
August 27, 2002, and closed on September 18, 2002. Of the 740 licenses 
available for auction, 484 licenses were sold to 102 winning bidders. 
Seventy-two of the winning bidders claimed small business, very small 
business, or entrepreneur status and won a total of 329 licenses. A 
second auction commenced on May 28, 2003, and closed on June 13, 2003, 
and included 256 licenses: five EAG licenses and 251 CMA licenses. 
Seventeen winning bidders claimed small or very small business status 
and won 60 licenses,

[[Page 555]]

and nine winning bidders claimed entrepreneur status and won 154 
licenses.
    62. 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.''
    63. Advanced Wireless Services. In the AWS-1 Report and Order, the 
Commission adopted rules that affect applicants who wish to provide 
service in the 1710-1755 MHz and 2110-2155 MHz bands. The Commission 
did not know precisely the type of service that a licensee in these 
bands might seek to provide. Nonetheless, the Commission anticipated 
that the services that will be deployed in these bands may have capital 
requirements comparable to those in the broadband Personal 
Communications Service (PCS), and that the licensees in these bands 
will be presented with issues and costs similar to those presented to 
broadband PCS licensees. Further, at the time the broadband PCS service 
was established, it was similarly anticipated that it would facilitate 
the introduction of a new generation of service. Therefore, the AWS-1 
Report and Order adopts the same small business size definition that 
the Commission adopted for the broadband PCS service and that the SBA 
approved. In particular, the AWS-1 Report and Order defines a ``small 
business'' as an entity with average annual gross revenues for the 
preceding three years not exceeding $40 million, and a ``very small 
business'' as an entity with average annual gross revenues for the 
preceding three years not exceeding $15 million. The AWS-1 Report and 
Order also provides small businesses with a bidding credit of 15 
percent and very small businesses with a bidding credit of 25 percent.
    64. Broadband Radio Service and Educational Broadband Service. 
Broadband Radio Service (``BRS''), formerly known as Multipoint 
Distribution Service (``MDS''), and Educational Broadband Service 
(``EBS''), formerly known as Instructional Television Fixed Service 
(``ITFS''), use frequencies at 2150-2162 and 2500-2690 MHz to transmit 
video programming and provide broadband services to residential 
subscribers. 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 high-speed Internet access services. 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 generating $13.5 million 
or less in annual receipts, appears applicable to MDS and ITFS. Other 
standards also apply, as described.
    65. The Commission has defined small MDS (now BRS) entities in the 
context of Commission license auctions. In the 1996 MDS auction, 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. This definition of a small entity in the context of MDS 
auctions has been approved by the SBA. 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. 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.
    66. 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). 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.
    67. Common Carrier Paging. As noted, the SBA has developed a small 
business size standard for wireless firms within the broad economic 
census category of ``Wireless Telecommunications Carriers (except 
Satellite).'' Under this category, the SBA deems a business to be small 
if it has 1,500 or fewer employees. Since 2007, the SBA has recognized 
wireless firms within this new, broad, economic census category. Prior 
to that time, the SBA had developed a small business size standard for 
wireless firms within the now-superseded census categories of 
``Paging'' and ``Cellular and Other Wireless Telecommunications.'' 
Under the present and prior categories, the SBA has deemed a wireless 
business to be small if it has 1,500 or fewer employees. Because Census 
Bureau data are not yet available for the new category, we will 
estimate small business prevalence using the prior categories and 
associated data. For the first category of Paging, data for 2002 show 
that there were 807 firms that operated for the entire year. Of this 
total, 804 firms had employment of 999 or fewer employees, and three 
firms had employment of 1,000 employees or more. For the second 
category of Cellular and Other Wireless Telecommunications, data for 
2002 show that there were 1,397 firms that operated for the entire 
year. Of this total, 1,378 firms had employment of 999 or fewer 
employees, and 19 firms had employment of 1,000 employees or more. 
Thus, using the prior categories and the available data, we estimate 
that the majority of wireless firms can be considered small. Thus, 
under this category, the majority of firms can be considered small.
    68. 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. A ``small 
business'' is an entity that, together with its affiliates and 
controlling principals, has average gross revenues not exceeding $15 
million for the preceding three years. Additionally, a ``very small 
business'' is an entity that, together with its affiliates and 
controlling principals, has average gross revenues that are not more 
than $3 million for the preceding three years. The SBA has approved 
these small business size standards. An auction of Metropolitan 
Economic Area licenses commenced on February 24, 2000, and closed on 
March 2, 2000. Of the 985 licenses auctioned, 440 were sold. Fifty-
seven companies claiming small business status won. Also, according to 
Commission data, 365 carriers reported that they were engaged in the 
provision of paging and messaging services. Of those, we estimate that 
360 are small, under the SBA-approved small business size standard.
    69. Wireless Communications Service. This service can be used for 
fixed, mobile, radiolocation, and digital audio

[[Page 556]]

broadcasting satellite uses. The Commission established small business 
size standards for the wireless communications services (WCS) auction. 
A ``small business'' is an entity with average gross revenues of $40 
million for each of the three preceding years, and a ``very small 
business'' is an entity with average gross revenues of $15 million for 
each of the three preceding years. The SBA has approved these small 
business size standards. The Commission auctioned geographic area 
licenses in the WCS service. In the auction, there were seven winning 
bidders that qualified as ``very small business'' entities, and one 
that qualified as a ``small business'' entity.
    70. 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.
    71. 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.
    72. NCE and Public Broadcast Stations. The Census Bureau defines 
this category as follows: ``This industry comprises establishments 
primarily engaged in broadcasting images together with sound. These 
establishments operate television broadcasting studios and facilities 
for the programming and transmission of programs to the public.'' The 
SBA has created a small business size standard for Television 
Broadcasting entities, which is: such firms having $13 million or less 
in annual receipts. According to Commission staff review of the BIA 
Publications, Inc., Master Access Television Analyzer Database as of 
May 16, 2003, about 814 of the 1,220 commercial television stations in 
the United States had revenues of $12 (twelve) million or less. We 
note, however, that in assessing whether a business concern qualifies 
as small under the above definition, business (control) affiliations 
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.
    73. In addition, an element of the definition of ``small business'' 
is that the entity not be dominant in its field of operation. We are 
unable at this time to define or quantify the criteria that would 
establish whether a specific television station is dominant in its 
field of operation. Accordingly, the estimate of small businesses to 
which rules may apply do not exclude any television station from the 
definition of a small business on this basis and are therefore over-
inclusive to that extent. Also as noted, an additional element of the 
definition of ``small business'' is that the entity must be 
independently owned and operated. We note that it is difficult at times 
to assess these criteria in the context of media entities and our 
estimates of small businesses to which they apply may be over-inclusive 
to this extent. There are also 2,117 low power television stations 
(LPTV). 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.
    74. The Commission has, under SBA regulations, estimated the number 
of licensed NCE television stations to be 380. We note, however, that, 
in assessing whether a business concern qualifies as small under the 
above definition, business (control) affiliations 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.

Description of Projected Reporting, Recordkeeping, and Other Compliance 
Requirements

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

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

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

[[Page 557]]

others): ``(1) the establishment of differing compliance or reporting 
requirements or timetables that take into account the resources 
available to small entities; (2) the clarification, consolidation, or 
simplification of compliance and reporting requirements under the rule 
for such small entities; (3) the use of performance rather than design 
standards; and (4) an exemption from coverage of the rule, or any part 
thereof, for such small entities.''
    77. 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

    78. None.

Ex Parte Rules

    66. These matters shall be treated as a ``permit-but-disclose'' 
proceeding in accordance with the Commission's ex parte rules. 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. Other requirements 
pertaining to oral and written presentations are set forth in section 
1.1206(b) of the Commission's rules.

Ordering Clauses

    67. 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.
    68. 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.
    69. 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.

Appendix A--Commercial Mobile Service Alert Advisory Committee 
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.

Table of Contents

1 Introduction and Executive Summary
    1.1 Executive Summary
    1.1.1 Reference Architecture (Section 2)
    1.1.2 Deployment Scenarios (Section 3)
    1.1.3 CMAS Alert Scenarios (Section 4)
    1.1.4 General Recommendations and Conclusions (Section 5)
    1.1.5 Service Profiles (Section 6)
    1.1.6 Mobile Device Functionality for CMAS Alerts (Section 7)
    1.1.7 Security for CMAS Alerts (Section 8)
    1.1.8 CMAS Reliability & Performance (section 9)
    1.1.9 Interface Protocols for CMAS Alerts (Section 10)
    1.2 Definitions
    1.3 Acronyms
2 Reference Architecture
    2.1 Functional Reference Model Diagram
    2.2 Government Administered Elements Definitions & Requirements
    2.2.1 Reference Point A
    2.2.2 Alert Aggregator
    2.2.3 Reference Point B
    2.2.4 Alert Gateway
    2.2.4.1 General Alert Gateway System Requirements
    2.2.4.2 CMSP Profile Support
    2.3 CMSP Administered Elements Definitions & Requirements
    2.3.1 Reference Point C
    2.3.2 CMSP Gateway
    2.3.3 CMSP Infrastructure
    2.3.4 Reference Points D & E
    2.3.5 Mobile Device
3 Deployment Scenarios
    3.1 Scenarios for Single Technology Deployed
    3.1.1 Scenario--CMAS in Entire Single Technology Operator 
Network on All Devices
    3.1.2 Scenario--CMAS in Entire Single Technology Operator 
Network on a Subset of Devices
    3.1.3 Scenario--CMAS in Subset of Single Technology Operator's 
Network on All Devices
    3.1.4 Scenario--CMAS in Subset of Single Technology Operator's 
Network on Subset of Devices
    3.2 Scenarios for Multiple Technologies Deployed
    3.2.1 Scenario--CMAS in Entire Multiple Technology Operator 
Network on All Devices
    3.2.2 Scenario--CMAS in Entire Multiple Technology Operator 
Network on Subset of Devices
    3.2.3 Scenario--CMAS in Subset of Multiple Technology Operator 
Network on Subset of Devices
    3.3 Scenario for Operator Does Not Elect to Transmit CMAS Alerts
    3.4 Subscriber Notification Recommendations
    3.4.1 Notification Procedures
    3.4.2 Notification Text Recommendations
4 CMAS Alert Scenarios
    4.1 Nominal CMAS Alert Scenarios
    4.1.1 Scenario for Nominal Text CMAS Alert
    4.1.1.1 Pre-Conditions
    4.1.1.2 Normal Flow
    4.1.2 Scenario for Nominal Streaming Audio or Streaming Video 
CMAS Alert
    4.1.3 Scenario for Nominal Downloaded Multimedia CMAS Alert
    4.2 CMAS Alert Cancellation Scenario
    4.2.1 Pre-Conditions
    4.2.2 Normal Flow
    4.3 CMAS Alert Update Scenarios
    4.3.1 Scenario for Update of Text CMAS Alert
    4.3.1.1 Pre-Conditions
    4.3.1.2 Normal Flow
    4.3.2 Scenario for Update of Streaming Audio or Streaming Video 
CMAS Alert
    4.3.3 Scenario for Update of Downloaded Multimedia CMAS Alert
    4.4 CMAS Alert Expiration Scenario
    4.4.1 Pre-Conditions
    4.4.2 Normal Flow
    4.5 Duplicate CMAS Alerts Scenarios
    4.5.1 Scenario for Duplicate CMAS Alerts on Same Broadcast 
Technology
    4.5.1.1 Pre-Conditions
    4.5.1.2 Normal Flow
    4.5.2 Scenario for Duplicate CMAS Alerts on Different Broadcast 
Technologies
    4.5.2.1 Pre-Conditions
    4.5.2.2 Normal Flow
    4.6 Multiple Different Active CMAS Alerts Scenario
    4.6.1 Pre-Conditions
    4.6.2 Normal Flow
5 General Requirements & Conclusions
    5.1 Scope & Definition of CMAS Alerts
    5.2 General CMAS Requirements & Conclusions
    5.3 Recommendations for Alert Initiation & Alert Initiators
    5.3.1 CMAM Elements
    5.3.2 Generating CMAM From CAP Fields
    5.3.2.1 Generating CMAM From Free Form Text
    5.3.3 Presidential Message and AMBER Alert
    5.3.4 Recommended Message Initiator Training
    5.4 Recommendations for Geo-Targeting of CMAS Alerts

[[Page 558]]

    5.5 Requirements and Recommendations on Needs of Users, 
Including Individuals with Disabilities and the Elderly
    5.5.1 General Requirements
    5.5.2 User Needs Requirements
    5.5.2.1 Alert/Attention Signal
    5.5.2.2 Message Content
    5.5.2.3 Output Mode/Display
    5.5.2.4 Behavior on Receipt of a Message
    5.5.2.5 CMAS-Related Print and Online Materials
    5.5.3 Subscriber CMA Opt-Out Recommendations
    5.6 Recommendations for CMAM Transmissions
    5.7 Multi-Language CMAS Alerts Recommendations
    5.8 CMAS Reception Control on Mobile Devices
    5.9 Roaming
6 Service Profiles
    6.1 Conclusions on Text, Audio, Video & Multimedia Resources
    6.2 Text Profile
    6.3 Streaming Audio Profile (future capability)
    6.4 Streaming Video Profile (future capability)
    6.5 Downloaded Multimedia Profile (future capability)
7 Mobile Device Functionality for CMAS Alerts
    7.1 General Requirements on Mobile Device Functionality
    7.2 Mobile Device Audio Attention Signal & Vibration Cadence 
Recommendations
    7.3 CMAS Functionality on Mobile Device
    7.4 Impact to Mobile Device Battery Life
8 Security for CMAS Alerts
    8.1 Alert Interface & Aggregator Trust Model
    8.1.1 Trust Model Definitions
    8.1.2 Trust Model Requirements
    8.2 Alert Gateway Security Requirements
    8.3 Reference Point C Security
    8.4 Reference Points D & E Security
9 CMAS Reliability & Performance
    9.1 Alert Gateway Performance Requirements
    9.2 Alert Delivery Latency
    9.3 CMAS End-to-End Reliability
    9.4 Message Logging
    9.4.1 Alert Gateway Logging
    9.5 CMAS Testing
    9.5.1 General CMAS Testing Recommendations
    9.5.2 Alert Gateway Testing
10 Interface Protocols for CMAS Alerts
    10.1 Reference Point A Protocol
    10.2 Reference Point B Protocol
    10.3 Alert Gateway Interfaces & Mapping Requirements
    10.3.1 Alert Gateway Interface Requirements
    10.3.2 Alert Gateway Interface Mapping Requirements
    10.4 Reference Point C Protocol
    10.4.1 Structure of the CMA ``C'' Reference Point Protocol
    10.4.2 CMAC Data Dictionary
    10.4.2.1 CMAC--Alert--Attributes Segment
    10.4.2.2 CMAC--Alert--Info Segment
    10.4.2.3 CMAC--Area Segment:
    10.4.2.4 CMAC--Resource Segment:
    10.4.3 Example CMAC XML Schema
    10.4.4 Element Mapping from B Reference Point (CAP) to C 
Reference Point (CMAC) to E Reference Point (CMAE) Elements
    10.4.5 Definition of CMAC--cmas--geocode Element
    10.4.6 Definition of CMAC Response Codes
    10.4.7 Example CMAS ``C'' Interface Alert Messages
    10.5 Reference Point E Protocols
11 Annex A--Anticipated Peak & Average CMAS Traffic Volume
12 Annex B--WARN Act Statutory Requirements
    12.1 WARN Act Requirements
    12.2 WARN Act Interpretations
    12.2.1 CMSP Election
    12.3 Licensees and Permittees of Noncommercial Educations 
Broadcasting Stations or Public Television Stations

List of Figures

Figure 2-1 CMAS Functional Reference Model
Figure 3-1 CMAS in Entire Single Technology Network on All Devices
Figure 3-2 CMAS in Entire Network on Sub-set of Devices
Figure 3-3 CMAS in Subset of Single Technology Operator's Network on 
All Devices
Figure 3-4 CMAS in Subset of Single Technology Operator's Network on 
Subset of Devices
Figure 3-5 CMAS in Entire Multiple Technology Operator Network on 
All Devices
Figure 3-6 CMAS in Entire Multiple Technology Operator Network on 
Subset of Devices
Figure 3-7 CMAS in Subset of Multiple Technology Operator Network on 
Subset of Devices
Figure 3-8 Operator Does Not Elect to Transmit CMAS Alerts
Figure 4-1 Flow for Scenario for Nominal Text CMAS Alert
Figure 4-2 Flow for CMAS Alert Cancellation Scenario
Figure 4-3 Flow for Scenario for Update of Text CMAS Alert
Figure 4-4 Flow for CMAS Alert Expiration Scenario
Figure 4-5 Flow for Scenario for Duplicate CMAS Alerts on Same 
Broadcast Technology
Figure 4-6 Flow for Scenario for Duplicate CMAS Alerts on Different 
Broadcast Technologies
Figure 4-7 Flow for Scenario for Multiple Different Active CMAS 
Alerts Scenario
Figure 10-1 Relationship of CAP Elements to Reference Point C 
Elements
Figure 10-2 CMAC Message Structure
Figure 12-1 Potential Deployment Timeline

List of Tables

Table 2-1 CMSP Profile on Alert Gateway
Table 5-1 CAP Value Field Mapping to Text
Table 6-1 Text Profile
Table 6-2 Streaming Audio Profile
Table 6-3 Video Profile
Table 6-4 Downloaded Multimedia Profile
Table 10-1 Parameter Mapping from ``B'' Interface CAP Message in to 
``C'' Interface CMAC message
Table 10-2 CMAC--Alert--Attributes Segment
Table 10-3 CMAC--Alert--Info Segment
Table 10-4 CMAC--Area Segment
Table 10-5 CMAC--Resource Segment
Table 10-6 Mapping Reference Point B Elements to Reference Point C 
Elements
Table 10-7 CMAC--cmas--geocode Assignments
Table 10-8 Reference Point E Protocol Elements
Table 11-1 Table of Total 2006 Tornado & Flash Flood Warnings by 
State
Table 11-2 Table of 2006 Tornado & Flash Flood Warnings by State by 
Month
Table 11-3 Estimated CMA Volume by Month

1 Introduction and Executive Summary

1.1 Executive Summary

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

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

    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:
    Within one year after the enactment of this Act, the Advisory 
Committee shall develop and submit to the Federal Communications 
Commission recommendations--
    (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

[[Page 559]]

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.
    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.1.1 Reference Architecture (Section 2)

    This section recommends a functional reference model for the 
distribution of alerts to Commercial Mobile 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)
---------------------------------------------------------------------------

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

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

    \5\ WARN Act, Sec.  602(c).
---------------------------------------------------------------------------

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

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

[[Page 560]]

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.

1.1.8 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 an end-to-end 
basis.

1.1.9 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 deliver CMAS alerts to the CMSP gateway. CAP mapping 
parameters are provided in detail.

1.2 Definitions

    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.
    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.
    Commercial Mobile Alert Service (CMAS)--The term CMAS refers to 
the end-to-end architecture for delivery of emergency alert messages 
subject to the WARN Act.
    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\
---------------------------------------------------------------------------

    \6\ WARN Act, Sec.  602(b)(1)(A).
---------------------------------------------------------------------------

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

2 Reference Architecture

[[Page 561]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.000

2.2 Government Administered Elements Definitions & Requirements

    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.

2.2.1 Reference Point A

    The actions to be performed at Reference Point A include the 
following:
    1. Provide information for the authentication and validation of 
actions across this reference point.
    2. Delivery of a new, updated, or cancelled wireless alert 
message to Alert Distribution Network in CAP format.
    3. Acknowledgement from Alert Gateway to Alert Aggregator that 
the new, updated, or cancelled wireless alert message has been 
received by the Alert Gateway.

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:
    1. 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)
    2. The Alert Aggregator will be operated according to the 
requirements set forth in the Trust Model.
    3. The authorized government entity will publish open non-
proprietary standards for message origination
    4. The Alert Aggregator will utilize CAP as the messaging 
standard to the Alert Gateway.
    5. 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.
    6. 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.
    7. 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:
    1. Carry forward information for the authentication and 
validation of actions across this reference point.
    2. Delivery of a new, updated, or cancelled wireless alert 
message to Alert Gateway in CAP format.
    3. 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

    The functions to be performed by the Alert Gateway include the 
following:
    1. Ensure authenticity of interactions with the Alert Aggregator 
and the CMSP Gateway.
    2. Validate (e.g., authentication and non-repudiation) the 
received wireless alert message.
    3. Maintain a log of wireless alert messages received from the 
Alert Aggregator and delivered to and rejected by the CMSP Gateway.
    4. 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.
    5. Stores CMSPs profiles including the CMSP election within a 
specific service area, supported technologies including any 
associated service profiles, characteristics, restrictions, 
limitations, or parameters.
    6. Deployment to achieve geographic separation from the CMSP 
Gateway.
    7. Support interfacing with multiple CMSPs and with multiple 
CMSP Gateways per CMSP.
    8. Geographically redundant Alert Gateway to avoid a single 
point of failure.

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

[[Page 562]]



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

2.3 CMSP Administered Elements Definitions & Requirements

2.3.1 Reference Point C

    The CMSAAC recommends that the actions to be performed by 
Reference Point C include the following:
    1. Provide information for the authentication and validation of 
actions across this reference point.
    2. 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.
    3. Acknowledgement from CMSP Gateway to Alert Gateway that the 
new, updated, or cancelled wireless alert message has been received 
by the CMSP Gateway.

2.3.2 CMSP Gateway

    The CMSAAC recommends that the functions to be performed by the 
Commercial Mobile Service Provider Gateway include the following:
    1. Authentication of interactions with the Alert Gateway.
    2. Management of Commercial Mobile Service Provider elections to 
support CMAS alert services within the Commercial Mobile Service 
Provider's service areas.
    3. Determination if CMSP has elected to offer CMAS alert 
services within the specified alerting area.
    4. Determination of which delivery technology or delivery 
technologies will be utilized for the transmission of CMAS alert 
messages within the specified alerting area.
    5. Map the alert area of the CMAS alert message into the 
associated set of cell sites/paging transceivers.
    6. Manage and execute CMAS alert retransmission subject to 
delivery technology capability and CMSP policy.
    7. A CMSP that elects to transmit alerts will have one or more 
CMSP Gateways designated for receipt of alerts from the Alert 
Gateway.
    8. The CMSP Gateway should have redundancy and be designed to 
provide high reliability and availability comparable to similarly 
situated network elements.
    9. 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.
    11. The CMSP Gateway will support the defined CMAS ``C'' 
interface and associated protocols between the Alert Gateway and the 
CMSP Gateway.
    12. The interface from the CMSP Gateway to the CMSP 
Infrastructure is CMSP and technology dependent and is not specified 
in CMAS.
    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:
    a. Authentication.
    b. Message integrity.
    c. Availability (i.e. keep alive messages).
    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.
    16. The CMSP Gateway will support a mechanism to handle 
congestion within the CMSP Infrastructure according to CMSP policy.
    17. The CMSP Gateway will not be responsible for performing any 
formatting, re-formatting, or translation of the CMAM other than the 
following:
    a. 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.
    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.
    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

    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:
    1. 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.
    2. 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.
    3. 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

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

    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

[[Page 563]]

technology advances. The following are general guidelines 
recommended by the CMSAAC for the functions to be performed by the 
Mobile Device:
    1. Authentication of interactions with the CMSP infrastructure. 
The authentication will not be part of the CMAS alert and is 
delivery technology dependent.
    2. Determination of delivery technology or delivery technologies 
being supported by the Commercial Mobile Service Provider in the 
subscriber's current visited network.
    3. Monitor associated channel or channels according to the 
requirements of the delivery technology or delivery technologies for 
CMAS alerts.
    4. Maintain configuration of CMAS alert options including the 
following:
    a. Subscriber's choice of CMAS alert opt-out selections.
    b. Subscriber's preferred language for CMAS alerts if applicable 
to the delivery technology.
    c. Default language is English if CMAS alert is not being 
transmitted in subscriber's preferred language.
    5. 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.
    6. 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.
    a. Presidential level CMAS alerts are always presented.
    b. Presentation of a CMAS alert will activate associated visual, 
audio, and mechanical (e.g., vibration) indicators per subscriber 
options configured on the mobile device.
    7. Detection and suppression of presentation of duplicate CMAS 
alerts.
    8. 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).

3 Deployment Scenarios

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

    \7\ WARN Act, Sec.  602(b)(1)(B).
---------------------------------------------------------------------------

     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:
    1. Potential date of initial deployment.
    2. Potential date when mobile device(s) with CMAS support are 
available for consumer purchase.
    3. Whether the deployment will be ``in whole or in part''.
    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.

    Note: The following diagrams show 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.

3.1 Scenarios for Single Technology Deployed

3.1.1 Scenario--CMAS in Entire Single Technology Operator Network on 
All Devices

    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.

[[Page 564]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.001

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

    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.

[[Page 565]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.002

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.

[[Page 566]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.003

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.

[[Page 567]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.004

3.2 Scenarios for Multiple Technologies Deployed

3.2.1 Scenario--CMAS in Entire Multiple Technology Operator Network on 
All Devices

    This scenario illustrates where the CMSP deploys 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.

[[Page 568]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.005

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 delivery 
technology.

[[Page 569]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.006

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.

[[Page 570]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.007

3.3 Scenario for Operator Does Not Elect to Transmit CMAS Alerts

    This option illustrates where the CMSP does not elect to 
transmit CMAS alerts.
[GRAPHIC] [TIFF OMITTED] TP03JA08.008


[[Page 571]]



3.4 Subscriber Notification Recommendations

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

    [[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 WEB SITE 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).

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:
     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.
     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.
     Duplicate CMAS alert scenarios for both duplicate CMAS 
alerts on the same broadcast technology and duplicate CMAS alerts 
from different broadcast technologies.
     Multiple different active CMAS alert scenarios.
     Multiple different CMAS alerts.

4.1 Nominal CMAS Alert Scenarios

4.1.1 Scenario for Nominal Text CMAS Alert

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

    1. Mobile device is authorized and authenticated for service on 
CMSP network.
    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of the CMA (e.g., not busy, not on a voice call).
    4. No previous Commercial Mobile Alert Message (CMAM) is being 
broadcast by the CMSP.
    5. There is no active CMAM on mobile device.
    6. CMSP subscriber is within the alerting area for the CMA.

4.1.1.2 Normal Flow

    The normal flow for the text based CMA is described in the 
following steps and in the associated flow diagram which follows:
    1. The appropriate government entity creates the alert message 
in CAP format which is sent to the government alerting network over 
Reference Point A.
    2. The government alerting network validates and authenticates 
the received alert request.
    a. 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.
    3. 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.
    4. The text profile based CMAM is sent to the CMSP over 
Reference Point C.
    5. The CMSP validates the received CMAM.
    a. 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.
    6. The CMSP sends an acknowledgement to the government alerting 
network that a valid CMAM has been received.
    7. 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.
    a. If the CMSP does not support CMAS in the indicated alert 
area, the CMAM is not broadcast by the CMSP. End of scenario.
    b. 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.
    c. 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.
    8. The CMSP broadcasts the CMAM 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 CMSP selected technology.
    9. 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.
BILLING CODE 6712-01-P

[[Page 572]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.009

BILLING CODE 6712-01-C

4.1.2 Scenario for Nominal Streaming Audio or Streaming Video CMAS 
Alert Streaming audio or streaming video CMAS alerts are a future 
capability.

4.1.3 Scenario for Nominal Downloaded Multimedia CMAS Alert Downloaded 
multimedia CMAS alerts are a future capability.

4.2 CMAS Alert Cancellation Scenario

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

    1. Mobile device is authorized and authenticated for service on 
CMSP network.
    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of the CMA (e.g., not busy, not on a voice call).
    4. 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).
    6. CMSP subscriber is within the alerting area of the active 
CMA.

4.2.2 Normal Flow

    The normal flow for the cancelled CMA is described in the 
following steps and in the associated flow diagram which follows:
    1. The appropriate government entity creates the alert 
cancellation message in CAP format which is sent to the government 
alerting network over Reference Point A.

[[Page 573]]

    2. The government alerting network validates and authenticates 
the received alert cancellation request.
    a. 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.
    a. 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.
    b. If the alert fails conversion, the alert cancellation is not 
sent to the CMSP. End of scenario.
    4. The CMAM cancellation is sent to the CMSP over Reference 
Point C.
    5. The CMSP validates the received CMAM cancellation.
    a. 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.
    6. The CMSP sends an acknowledgement to the government alerting 
network that a valid CMAM cancellation has been received.
    7. The CMSP discontinues the broadcasts the associated CMAM 
including the text component and any associated audio, video, or 
multimedia components.
    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.
    a. If the CMSP does not support CMAS in the indicated alert 
area, the CMAM is not broadcast by the CMSP. End of scenario.
    b. 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.
    c. 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.
    9. 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.
    10. The mobile device monitors for the broadcast of the CMAM 
cancellation via the CMSP selected technology and receives the CMAM 
cancellation.
    a. 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.

[[Page 574]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.010

4.3 CMAS Alert Update Scenarios

4.3.1 Scenario for Update of Text CMAS Alert

    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.
    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.
    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 expiration or 
until a valid CMAM cancellation is received.

4.3.1.1 Pre-Conditions

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

[[Page 575]]

    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of the CMA (e.g., not busy, not on a voice call).
    4. The CMSP may be broadcasting a previous CMA which is 
associated with the updated CMA.
    5. A CMAM may be active on mobile device.
    6. CMSP subscriber is within the alerting area of the updated 
CMA.

4.3.1.2 Normal Flow

    The normal flow for the update of text based CMAM is described 
in the following steps and in the associated flow diagram which 
follows:
    1. The appropriate government entity creates the updated alert 
message in CAP format which is sent to the government alerting 
network over Reference Point A.
    2. The government alerting network validates and authenticates 
the received updated alert request.
    a. 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.
    3. The government alerting network converts the received alert 
message into the text profile based CMAS format supported by the 
CMSP.
    a. 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.
    b. If the alert fails conversion, the alert is not sent to the 
CMSP. End of scenario.
    4. The updated text based CMAM is sent to the CMSP over 
Reference Point C.
    5. The CMSP validates the received updated CMAM.
    a. 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.
    6. The CMSP sends an acknowledgement to the government alerting 
network that a valid updated CMAM has been received.
    7. The CMSP discontinues any broadcasts of the previously issued 
CMAM.
    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 updated CMAM.
    a. If the CMSP does not support CMAS in the indicated alert 
area, the updated CMAM is not broadcast by the CMSP. End of 
scenario.
    b. 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.
    c. 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. 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.
    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.

[[Page 576]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.011

4.3.2 Scenario for Update of Streaming Audio or Streaming Video CMAS 
Alert

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

4.3.3 Scenario for Update of

    Downloaded Multimedia CMAS Alert
    Downloaded multimedia CMAS alerts are a future capability.

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.

4.4.1 Pre-Conditions

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

[[Page 577]]

4.4.2 Normal Flow

    The normal flow for the CMAS alert expiration is described in 
the following steps and in the associated flow diagram which 
follows:
    1. The expiration time of a previously issued CMAM has been 
determined by the CMSP.
    2. Any active broadcasts of text component of the previously 
issued CMAM are discontinued by the CMSP.
    3. All active broadcasts of any associated audio, video, or 
multimedia components of the previously issue CMAM are discontinued 
by the CMSP.
[GRAPHIC] [TIFF OMITTED] TP03JA08.012

4.5 Duplicate CMAS Alerts Scenarios

4.5.1 Scenario for Duplicate CMAS Alerts on Same Broadcast Technology

    A CMAM is being retransmitted by the CMSP network. The mobile 
device detects and ignores the duplicate CMAM.
    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.1.1 Pre-Conditions

    1. Mobile device is authorized and authenticated for service on 
CMSP network.
    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of CMAM (e.g., not busy, not on a voice call).
    4. A previous copy of the CMAM has been broadcast by the CMSP.
    5. The previous copy of the CMAM is contained on mobile device.
    6. CMSP subscriber is still within the alerting area for the 
CMA.

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:
    1. The CMSP network retransmits a previously broadcast CMAM.
    a. The CMAM being retransmitted contains the same message 
identifier as the previously broadcast version.
    b. The retransmission could be performed by the CMSP selected 
delivery technology depending on the capabilities of the delivery 
technology.
    2. The mobile device monitors for the broadcast of the CMAM via 
the CMSP selected technology.
    3. 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.

[[Page 578]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.013

4.5.2 Scenario for Duplicate CMAS Alerts on Different Broadcast 
Technologies

    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. Support of multiple broadcast technologies 
by the CMSP network may be result of the deployment and 
implementation of newer broadcast technologies. 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.1 Pre-Conditions

    1. Mobile device is authorized and authenticated for service on 
CMSP network.
    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of the CMA (e.g., not busy, not on a voice call).
    4. No previous CMAM is being broadcast by the CMSP.
    5. There is no active CMAM on mobile device.
    6. CMSP subscriber is still within the alerting area for the 
CMA.
    7. The mobile device is capable of receiving the CMAM from more 
than one broadcast technology.

4.5.2.2 Normal Flow

    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:
    1. The appropriate government entity creates the alert message 
in CAP format which is sent to the government alerting network over 
Reference Point A.
    2. The government alerting network validates and authenticates 
the received alert request.
    a. 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.
    3. 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.
    4. The text profile based CMAM is sent to the CMSP over 
Reference Point C.
    5. The CMSP validates the received CMAM.
    a. 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.
    6. The CMSP sends an acknowledgement to the government alerting 
network that a valid CMAM has been received.
    7. 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.
    a. If the CMSP does not support CMAS in the indicated alert 
area, the CMAM is not broadcast by the CMSP. End of scenario.
    b. 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.
    c. 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.
    8. 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.
    9. 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.
    c. 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

[[Page 579]]

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.
BILLING CODE 6712-01-P
[GRAPHIC] [TIFF OMITTED] TP03JA08.014

BILLING CODE 6712-01-C

[[Page 580]]

4.6 Multiple Different Active CMAS Alerts Scenario

    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.
    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. 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.6.1 Pre-Conditions

    1. Mobile device is authorized and authenticated for service on 
CMSP network.
    2. Mobile device is receiving adequate radio signal strength 
from the CMSP.
    3. Mobile device is in state that allows for the detection and 
reception of CMA (e.g., not busy, not on a voice call).
    4. No previous CMAM is being broadcast by the CMSP.
    5. There is no CMAM on mobile device.
    6. CMSP subscriber is within the alerting area for the CMA.
    7. Both CMA are to be issued for the same alerting area.

4.6.2 Normal Flow

    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:
    1. The appropriate government entity creates the 1st alert 
message in CAP format which is sent to the government alerting 
network over Reference Point A.
    2. The government alerting network validates and authenticates 
the 1st received alert request.
    a. 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.
    3. 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.
    4. The 1st text profile based CMAM is sent to the CMSP over 
Reference Point C.
    5. The CMSP validates the 1st received CMAM.
    a. 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.
    6. The CMSP sends an acknowledgement to the government alerting 
network that the 1st received CMAM is valid.
    7. 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.
    a. If the CMSP does not support CMAS in the indicated alert 
area, the 1st CMAM is not broadcast by the CMSP. End of scenario.
    b. 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.
    c. 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.
    8. The CMSP broadcasts the 1st CMAM to the set of cell sites/
paging transceivers identified by the geo-targeting processing in 
the previous step.
    a. The 1st CMAM is broadcast via the CMSP selected technology.
    9. 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.
    a. 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.
    b. 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.
    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.
    a. 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.
    a. 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.
    15. The CMSP sends an acknowledgement to the government alerting 
network that the 2nd received CMAM is valid.
    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.
    a. 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 geo-targeting processing step.
    a. The 2nd CMAM is broadcast via the CMSP selected technology.
    b. 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.
    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.
    a. 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.
    b. 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.
    c. The mobile device ignores the retransmission of the duplicate 
1st CMAM.
    d. 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.

[[Page 581]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.015

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.
    The CMSAAC recommends that this document be treated as a living 
document,

[[Page 582]]

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:
    1. Presidential-level.
    2. 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).
    3. Child Abduction Emergency or ``AMBER Alert''.
    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.
    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.
    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.
    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.
    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.
    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 non-
discriminatory intellectual property rights policy, allowing for 
multi-vendor implementations.
    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.
    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.
    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 General CMAS Requirements & Conclusions

    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.
    1. Federal, state, tribal, and local level CMAS alert messages 
will be supported using the same CMAS solution.
    2. 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:
    a. Point-to-point technologies can experience significant 
delivery delays.
    b. Point-to-point technologies can result in network and radio 
interface congestion to the point of blocking voice calls.
    c. Point-to-point technologies lack security and can be easily 
spoofed.
    d. Point-to-point technologies lack geo-targeting capabilities 
because it is targeted to phone numbers instead of a specific alert 
area.
    e. Point-to-point technologies lack emergency alert specific 
alert tones and thereby emergency alerts can not be distinguished 
from normal SMS message traffic.
    f. Point-to-point technologies lack support of roamers.
    3. 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.
    4. No new CALEA lawful intercept access points will be created 
for CMAS alert broadcast delivery technologies.
    5. 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.
    6. It is not a requirement to support CMAS on non-initialized 
mobile devices, including mobile devices that are not authorized for 
service.
    7. 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.
    a. 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 same channels as commercial mobile services. It is 
recognized that these technologies may provide supplemental alert 
information for the CMAS.
    8. The CMAMs are delivered across Reference Point C to the CMSP 
network at no cost to the CMSP.

5.3 Recommendations for Alert Initiation & Alert Initiators

5.3.1 CMAM Elements

    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 5 
p.m. 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).
    2. Area affected (in this area).
    3. Recommended action (Response description).
    4. Expiration time with time zone (Represented as a distinct 
time--e.g., until 09:30 a.m. EDT).
    5. Sending agency (agency type, i.e., police, fire, National 
Weather Service, etc.).

    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 the 
most efficient and informative format for the CMAMs.


[[Page 583]]



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 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.
    2. 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).
    3. 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.
    4. 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.--CAP Value Field Mapping to Text
------------------------------------------------------------------------
            CAP field                    Value            Text string
------------------------------------------------------------------------
                            What is happening
------------------------------------------------------------------------
category........................  Met...............  Severe Weather
                                                       Warning.
                                  Safety............  Public Safety
                                                       Warning.
                                  Fire..............  Fire Warning.
                                  Geo...............  Geologic Warning.
                                  Security..........  Security Warning.
                                  Rescue............  Rescue Alert.
                                  Health............  Health Warning.
                                  Env...............  Environmental
                                                       Warning.
                                  Transport.........  Transport Alert.
eventCode.......................  TOR...............  Tornado Warning.
                                  VOW...............  Volcano Warning.
                                  SVR...............  Severe TStorm
                                                       Warning.
                                  EQW...............  Earthquake
                                                       Warning.
                                  TSW...............  Tsunami Warning.
                                  BZW...............  Blizzard Warning.
                                  DSW...............  Dust Storm
                                                       Warning.
                                  FFW...............  Flash Flood
                                                       Warning.
                                  HWW...............  High Wind Warning.
                                  HUW...............  Hurricane Warning.
                                  TRW...............  Tropical Storm
                                                       Warning.
                                  WSW...............  Winter Storm
                                                       Warning.
                                  CFW...............  Coastal Flood
                                                       Warning.
                                  FLW...............  Flood Warning.
                                  FRW...............  Fire Warning.
                                  SMW...............  Special Marine
                                                       Warning.
                                  AVW...............  Avalanche Warning.
                                  CDW...............  Civil Danger
                                                       Warning.
                                  CEM...............  Civil Emergency.
                                  HMW...............  HazMat Warning.
                                  LEW...............  Police Warning.
                                  CAE...............  AMBER Alert.
                                  NUW...............  Nuclear Power
                                                       Plant Warning.
                                  RHW...............  Radiological
                                                       Hazard Warning.
------------------------------------------------------------------------

[[Page 584]]

 
                          What area is affected
------------------------------------------------------------------------
                                                      ..................
                                                      ``in this area''
------------------------------------------------------------------------
                         When the alert expires
------------------------------------------------------------------------
expires.........................  The expiration      Translated by the
                                   time of the         Alert Gateway to
                                   information of      an event expires
                                   the alert           time in a 12 hour/
                                   message. The date   Time zone format
                                   and time is         (i.e.,
                                   represented in      Until7:00AM PDT).
                                   [dateTime] format
                                   (e.g., ``2002-05-
                                   24T16:49:00-07:00
                                   '' for 24 May
                                   2002 at 16:49
                                   PDT).
------------------------------------------------------------------------
                       What action should be taken
------------------------------------------------------------------------
responseType....................  Shelter or SPW....  Take Shelter Now.
                                  Evacuate or EVI...  Evacuate Now.
                                  Prepare...........  Prepare for
                                                       Action.
                                  Execute...........  Execute Action.
                                  Avoid Hazard \8\..  Avoid Hazard.
------------------------------------------------------------------------
                        Who is sending the alert
------------------------------------------------------------------------
sender..........................  Identifies the      Translated by the
                                   originator of       Alert Gateway to
                                   this alert.         an acronym or
                                   Guaranteed by       short
                                   assigner to be      abbreviation
                                   unique globally;    picked by the
                                   e.g., may be        sender.
                                   based on an        Note: URLs, phone
                                   Internet domain     numbers, and
                                   name--could also    email addresses
                                   come from the       are not sent to
                                   sender's name in    the mobile
                                   the Trust Model.    device.
------------------------------------------------------------------------

5.3.2.1 Generating CMAM From Free Form Text
---------------------------------------------------------------------------

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

    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.
    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.
    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.
    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.
    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.
    The free form text for the CMAM should be included as a 
parameter of the CAP message with the valueName indicating 
``CMAMtext''.
    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.

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 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.
    2. 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 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.
    4. 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 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

    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

[[Page 585]]

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.
    Based upon current capabilities, the CMSAAC recommends the 
following for geo-targeting of CMAS alerts:
    1. 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.
---------------------------------------------------------------------------

    \9\ County, parish or equivalent jurisdictional area.
---------------------------------------------------------------------------

    a. 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.
    2. 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 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.
    3. 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.
    4. Transmission of alerts shall be to two-dimensional areas. 
There shall not be any altitude or ceiling component.

5.5 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\
---------------------------------------------------------------------------

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

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

5.5.2 User Needs Requirements

5.5.2.1 Alert/Attention Signal

    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

[[Page 586]]

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.
    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 color-blind, 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.
---------------------------------------------------------------------------

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

    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-to-speech. 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

    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 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 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.
    [cir] 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\
---------------------------------------------------------------------------

    \12\ WARN Act Sec.  602(b)(2)(E).
---------------------------------------------------------------------------

    [cir] ``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:

1. Presidential-level
2. Imminent threat to life and property
3. 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.

    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:
     All messages,\13\
---------------------------------------------------------------------------

    \13\ Presidential messages will still be received.
---------------------------------------------------------------------------

     All severe messages,\14\
---------------------------------------------------------------------------

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

     AMBER Alerts \15\
---------------------------------------------------------------------------

    \15\ All other messages will still be received.
---------------------------------------------------------------------------

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

[[Page 587]]

    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.

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

    \16\ WARN Act Sec.  603(c)(4)).
---------------------------------------------------------------------------

    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 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 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.
    b. 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.
    c. 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.
    d. 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.
    e. 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.
    2. 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:
    1. Roaming GSM subscribers receive CMAS alerts from GSM 
operators in the serving market.
    2. Roaming CDMA subscribers receive CMAS alerts from CDMA 
operators in the serving market.
    3. 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.
    4. 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.
    5. 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.

6 SERVICE PROFILES

    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)

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

[[Page 588]]

     Zero or more Downloaded Multimedia Profiles

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

6.1 Conclusions on Text, Audio, Video & Multimedia Resources

    1. 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.
    2. 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.
    3. The CMSP networks are outside the scope of the Trust Model of 
the government alerting infrastructure.
    4. 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.
    a. 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.
    b. Any audio, video, and multimedia files collected for the CMAS 
alert messages must be provided to the CMSPs in a standard set of 
formats.
    5. The CMSAAC recommends that the government alerting 
infrastructure be aligned with the capabilities and requirements as 
defined under the CMAS.
    a. 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.
    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   Size is estimated.
                               in Section 5.3.1,
                               the biennial review
                               committee shall
                               review whether the
                               character limit
                               profile may be
                               increased.).
Maximum Displayable Message   90 characters for an  Languages other than
 Size.                         English language      English, or coding
                               CMA encoded with 7-   other then 7-bit
                               bit encoding. (As     coding, will result
                               noted in Section      in a change to the
                               5.3.1, the biennial   maximum number of
                               review committee      characters
                               shall review          supported.
                               whether the
                               character limit
                               profile may be
                               increased.).
Data Coding Scheme..........  UTF-8 as defined in   The text on the C
                               IETF RFC-3629.        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.
------------------------------------------------------------------------

6.3 Streaming Audio Profile (Future Capability)

    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.
    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         Attribute definition          Note
------------------------------------------------------------------------
Purpose.....................  Define service        ....................
                               profile for
                               streaming audio
                               messages..
Maximum size................  Based upon the        Size of the
                               authorized            streaming audio
                               government entity     file is dependent
                               policy.               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       Identification of     See reference model.
 Scheme.                       the standard format
                               of the streaming
                               audio file being
                               retrieved by the
                               CMSP Gateway.
C interface Audio File        Issue of audio file   The contents of this
 Reference.                    transmissions         attribute are based
                               remains to be         upon the streaming
                               addressed.            audio file being
                                                     pulled by the CMSP
                                                     Gateway from the
                                                     Alert Gateway.
------------------------------------------------------------------------

6.4 Streaming Video Profile (Future Capability)

    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.
    This information is passed from the Alert Gateway to the CMSP 
Gateway and may include attributes that are generated by the CMAS 
alert originator.

[[Page 589]]



                        Table 6-3.--Video Profile
          [Service profile: Streaming--video--service--profile]
------------------------------------------------------------------------
       Attribute name         Attribute definition          Note
------------------------------------------------------------------------
Purpose.....................  Define service
                               profile for
                               streaming video
                               alert messages.
Maximum Size................  Based upon the        Size of the
                               authorized            streaming video
                               government entity     file is dependent
                               policy.               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       Identification of     See reference model.
 Scheme.                       the standard format
                               of the streaming
                               video file being
                               retrieved by the
                               CMSP Gateway.
C Interface Video File        Issue of video file   The contents of this
 Reference.                    transmissions         attribute are based
                               remains to be         upon the streaming
                               addressed.            video file being
                                                     pulled by the CMSP
                                                     Gateway from the
                                                     Alert Gateway.
------------------------------------------------------------------------

6.5 Downloaded Multimedia Profile (Future Capability)

    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.
    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          Note
------------------------------------------------------------------------
Purpose.....................  Define service
                               profile for CMAS
                               alerts with
                               multimedia files
                               for download to the
                               mobile device.
Maximum Size................  Based upon the        Size of the
                               authorized            multimedia file for
                               government entity     download is
                               policy.               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       Identification of     See reference model.
 Scheme.                       the standard format
                               of the multimedia
                               file being
                               retrieved by the
                               CMSP Gateway.
C Interface Multimedia File   Issue of multimedia   The contents of this
 Reference.                    file transmissions    attribute are based
                               remains to be         upon the multimedia
                               addressed.            file being pulled
                                                     by the CMSP Gateway
                                                     from the Alert
                                                     Gateway.
------------------------------------------------------------------------

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 of 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 of 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:
    1. Mobile device behavior is outside the scope of the WARN Act 
and, therefore, is not subject to recommendations by the CMSAAC.
    2. There be a common audio attention signal and a common 
vibration alert cadence for CMAM. (See Section 7.2 below.)
    3. 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 acknowledgment to the 
mobile device of alert messages) will be CMSP and mobile device 
specific.
    4. Legacy deployed mobile devices may not be supported. At a 
minimum, new CMAS functionality is needed on future mobile devices.
    a. New mobile devices will be introduced by normal market mobile 
device lifecycle replacement.
    b. Some legacy pager devices may be able to be updated with over 
the air programming.
    5. 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.
    6. CAP messages will not be delivered to mobile devices of the 
subscribers.

7.2 Mobile Device Audio Attention Signal & Vibration Cadence 
Recommendations

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

[[Page 590]]

    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.
    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 by two short 
tones of approximately 1 second each with approximately \1/2\ second 
gap between tones. The entire sequence is repeated twice with 
approximately \1/2\ second between repetitions. Temporal patterns of 
the CMAS audio attention signal are mobile device manufacturer 
specific.
    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.
    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.
    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.
    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.
    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.

7.3 CMAS Functionality on Mobile Device

    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.
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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 
attention signal and/or the special emergency alert vibration 
cadence is dependent on CMSP policies and mobile device 
capabilities.
    6. 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.
    7. 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.
    a. 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.
    b. Color cannot be used as the sole method for convening 
information. (See Section 5.5 above)

7.4 Impact to Mobile Device Battery Life

    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.
    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.
    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:
    (a) Delivery Technology (GSM, UMTS, CDMA2000 1x, Flex, Re-Flex, 
etc.).
    (b) Initial system network parameters before implementation of 
broadcast messaging.
    (c) Maximum latency to deliver the message over the E interface.
    (d) Retransmission interval.
    (e) Number of languages supported.
    (f) Number of alerts sent.
    (g) Alert Duration, and number of times the portable device 
alerts the user.
    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.
    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.
    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. 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 affect 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.
    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.

8 Security for CMAS Alerts

8.1 Alert Interface & Aggregator Trust Model

8.1.1 Trust Model Definitions

    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.
     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.
     Authority--Any public servant that is permitted by 
their jurisdiction to send a public alert and warning message.
     Capability--The nominated individual must demonstrate 
the knowledge of process,

[[Page 591]]

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.
     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.
     Certified system--will support the Trust Model and 
counter-signatory function to send public alert and warning 
messages.
     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

    The CMSAAC makes the following recommendations regarding Trust 
Model requirements:
    1. All messages will be attributed reliably to an individual 
sender.
    2. All messages will be accepted from individuals holding a 
specified credential or from a certified system which required 
individual credentials.
    3. 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.
    4. The CMSAAC recommends that a process be established by which 
credentials can be certified upon demonstration of identity, 
responsibility and capability.
    5. Identity, responsibility and capability must be recertified 
annually. All credentials will expire in 12 months.
    6. All messages entered into the system will be logged, this log 
will be maintained for a reasonable period of time to support an 
audit.
    7. The digital signatures will be bound to the message and 
carried from the originator to the Alert Gateway.
    8. The message transport layer from the originator to the Alert 
Gateway will utilize an existing open non-proprietary transport 
standard and shall be Internet Protocol based.

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:
    1. 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.
    2. 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.
    3. A single authorized source such as a designated government 
agency, or their authorized agent, will serve as the sole operator 
for the Alert Gateway.
    4. 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.
    5. The Alert Gateway will inform the alert originator via Alert 
Aggregator if the CMAS message was not accepted by the CMSP Gateway.

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.

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

    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:
    1. 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.
    2. 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.
    3. The Alert Gateway will provide a transmission control 
mechanism to buffer the CMAM traffic upon receiving an overload 
warning from the CMSP Gateway.
    4. 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.
    a. 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.
    b. 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.
    5. 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.
    6. 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.
    7. 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.
    8. 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.
    9. The Alert Gateway will be designed to have the service 
availability of 99.999%.
    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

    The CMSAAC recommends that, since latency will require 
experience in deployment, end-to-end latency requirements be 
addressed in the biennial review.
    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

[[Page 592]]

--Capabilities of the delivery technology
--Message queues
--Number of languages
--Number of targeted cell sites/paging transceivers for the alert 
area
--Geo-targeting processing

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

9.4 Message Logging

    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.
    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.
    The CMSAAC recommends that there be no requirements for the CMSP 
to retain logs for any period of time.

9.4.1 Alert Gateway Logging

    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.
    2. The Alert Gateway will maintain an online log of active and 
cancelled alert messages for 90 days.
    3. The Alert Gateway will maintain archived logs for a minimum 
of 36 months.
    4. The Alert Gateway will provide CMSPs access to online 
messaging logs and archived logs for testing and troubleshooting 
purposes.
    5. The Alert Gateway will generate monthly system and 
performance statistics reports based on CMA alerting category, 
alerting originator, alerting area and other alerting attributes.
    6. 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.

9.5 CMAS Testing

    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.
    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.
    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.
    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.
    The CMSAAC recommends that the keep-alive test messages not be 
sent if there are real messages to be sent.

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'.
    b. Provide the ability to send test messages to a single CMSP/
network without impact to other CMSPs.
    c. Provide the ability to test the CMAS up to the CMSP Gateway 
without impacting the CMSP infrastructure.
    2. Provide CMSP access to the CMAM logs from the Alert Gateway.
    3. Messages used for testing purposes shall be clearly 
differentiated from messages for actual events.

9.5.2 Alert Gateway Testing

    The CMSAAC recommends that the Alert Gateway support several 
types of testing:
    a. Functional testing for the C interface (not expected to be 
sent to the subscribers)
    b. Connection testing for new CMSP
    The CMSAAC further recommends the following requirements for 
Alert Gateway testing:
    1. 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.
    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. 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.
    4. All test messages for the C interface will be clearly marked 
and identified as test messages.

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


[[Page 593]]


 Message ID
 Sender ID
 Sent Date/Time
 Message Status
 Message Type
 Scope
 Event Category
 Urgency
 Severity
 Certainty
 Resource Description
 Area Description--A FIPS geo-code, a polygon or circle 
(WGS-84 format) will be used to support the area description.

    2. The Alert Aggregator will provide a mechanism to validate the 
identity of the individual sending the message to allow non-
repudiation.
    3. The implementer of the Alert Aggregator will provide a 
documented, non-proprietary, specification for transport that will 
support appropriate security and reliability.

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

10.3 Alert Gateway Interfaces & Mapping Requirements

10.3.1 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).
    2. The Alert Gateway will initially support CAP v1.1 as the 
application layer protocol for communicating with the Alert 
Aggregator.
    3. The Alert Gateway will uniquely identify each CMSP Gateway 
identified by a unique IP address or domain name.
    4. The Alert Gateway will support the ``C'' interface protocol 
as defined in Section 10.4 below.
    5. The Alert Gateway will support all CMAM formats that can be 
delivered to CMSP Gateway.
    6. 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.
    7. The Alert Gateway will support receiving acknowledgment from 
the CMSP Gateway that the CMAM has been received or rejected by the 
CMSP Gateway.
    8. 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.

10.3.2 Alert Gateway Interface Mapping Requirements

    The Alert Gateway will map the CMAMs received in CAP format into 
the CMAC format supported by the CMSP Gateway.
    1. 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.
    2. 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.
    3. Each CMAM will only include one language. The CMA issued in 
multiple languages will be issued by separate messages.
    4. All CMAM alert, update and 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.
    5. The Alert Gateway will not alter the content of text alert 
messages, with the exception of
    a. If CAP expires is not available, the default parameter value 
of one hour shall be used.
    b. 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.
    6. For Presidential 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, then
    b. Use Alert Gateway generated automatic text: ``The President 
has issued an emergency alert. Check local media for more details.''
    7. 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.
    8. For alerts other than the Presidential Alert or AMBER Alert, 
the Alert Gateway will support free-format text generation or 
automatic text generation.
    9. 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.
    10. For automatic text generation, the Alert Gateway will 
support the following rules to construct the message:
    a. 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.
    b. Area Affected: The Alert Gateway will use the phrase ``in 
this area''.
    c. 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.
    d. Area Affected: The Alert Gateway will use the phrase ``in 
this area''.
    e. 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.
    f. 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.
    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.
    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.
    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.
    15. The Geo-mapping of targeted area (cell sites) will be the 
responsibility of CMSPs and not a function of the Alert Gateway.
    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.
    18. The Alert Gateway will translate latitude/longitude 
coordinates into appropriate State or County Geocode if no State or 
County Geocode is provided by the alert originator.
    19. The Alert Gateway will not be required to translate State or 
County Geocode into latitude/longitude coordinates.
    20. The Alert Gateway will specify an agreed upon maximum number 
of latitude/longitude coordinates per polygon to be sent to the CMSP 
Gateway.
    21. If Geocode, polygon or circle is not provided for a 
Presidential Alert, the Alert Gateway will use ``Nation wide'' by 
default.
    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. For audio, video and multi-media CMAMs, if the CAP message 
includes the associated files, the Alert Gateway will
    a. Re-format, if necessary, the associated files into 
standardized format as specified in the associated service profile 
(see Section 6 above).

[[Page 594]]

    b. Store the associated files on the Alert Gateway to be 
retrieved by the CMSP Gateways.
    c. Send the message with proper URL so that CMSP Gateways can 
retrieve the files if they so choose.
    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
    a. Retrieve the associated files from the URL in the CAP 
message.
    b. Re-format, if necessary, the associated files into 
standardized format as specified in the associated service profile 
(see Section 6 above).
    c. Store the associated files on the Alert Gateway to be 
retrieved by the CMSP Gateway.
    d. Send the message with proper URL so that CMSP Gateway can 
retrieve the files if they so choose.
    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.
    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.
    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.
    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.
    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.
    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
----------------------------------------------------------------------------------------------------------------
                                                                Alert gateway filtering
             CAP element                (CMA) Permitted values           rules                 CMAC element
----------------------------------------------------------------------------------------------------------------
N/A..................................  .......................  Generated by the Alert   CMAC protocol version.
                                                                 Gateway.
N/A..................................  .......................  Generated by the Alert   CMAC sending Alert
                                                                 Gateway.                 Gateway id.
alert................................  N/A....................  Ignored................  N/A
identifier (free format).............  .......................  Mapped from the free     CMAC--message--identifi
                                                                 format into a 2 octet    er (2 octet binary
                                                                 binary number.           number).
sender...............................  .......................  Pass...................  CMAC--sender.
sent.................................  .......................  Mapped into UTC format.  CMAC--sent--date--time.
status...............................  ``Actual'' ``Exercise''  Pass with permitted      CMAC--status.
                                        ``System'' ``Test''.     values; Reject message
                                                                 with ``Draft''.
msgType..............................  ``Alert'' ``Update''     Pass with permitted      CMAC--message--type.
                                        ``Cancel'' ``Error''.    values; Reject message
                                                                 with ``Ack''.
source...............................  N/A....................  Ignored................
scope................................  ``Public''.............  Reject message if        N/A.
                                                                 ``Public'' is not in
                                                                 field..
restriction..........................  .......................  Reject message if this   N/A.
                                                                 element is included.
addresses............................  .......................  Reject message if this   N/A.
                                                                 element is included.
code.................................  .......................  Ignored................  N/A.
note.................................  .......................  Pass...................  CMAC--cancel--error--no
                                                                                          de.
references...........................  .......................  Mapped from the free     CMAC--referenced--messa
                                                                 format into a 2 octet    ge--identifier (2-
                                                                 binary number.           octet binary number).
incidents............................  N/A....................  Ignored................  N/A.
N/A..................................  .......................  Generated by the Alert   CMAC--original--cap--al
                                                                 Gateway.                 ert--uri.
info.................................  .......................  .......................  Ignored.
language.............................  .......................  Pass...................  CMAC--text--language.
category.............................  .......................  Mapped.................  CMAC--category.
event................................  N/A....................  Ignored................  N/A.
responseType.........................  All but ``Assess''.....  Reject message with      CMAC--response--type.
                                                                 ``Assess'' in field,
                                                                 pass all others.
urgency..............................  ``Immediate''            Pass with permitted      CMAC--urgency.
                                        ``Expected''.            values or rejecting
                                                                 message with other
                                                                 values.
severity.............................  ``Extreme'' ``Severe''.  Pass with permitted      CMAC--severity.
                                                                 values or rejecting
                                                                 message with other
                                                                 values.
certainty............................  ``Observed'' ``Likely''  Pass with permitted      CMAC--certainty.
                                                                 values or rejecting
                                                                 message with other
                                                                 values.
audience.............................  N/A....................  Ignored................  N/A.

[[Page 595]]

 
eventCode............................  ``EAN''................  Map ``EAN'' to           CMAC--special--handling
                                       ``CAE''................   ``Presidential'';.       .
                                                                Map ``CAE'' to ``Child
                                                                 Abduction'';.
                                                                Map other values to
                                                                 ``No special
                                                                 handling''.
eventCode............................  .......................  Mapped.................  CMAC--event--code.
effective............................  N/A....................  Ignored................  N/A.
onset................................  N/A....................  Ignored................  N/A.
expires..............................  .......................  Passed; Reject message   CMAC--expires--date--ti
                                                                 if already expired;.     me.
                                                                Apply default value of
                                                                 one hour if not
                                                                 provided.
senderName...........................  .......................  Mapped.................  CMAC--sender--name.
headline.............................  .......................  Passed conditionally     CMAC--text--alert--mess
                                                                 when eventCode=          age.
                                                                 ``EAN'' or ``CAE'';.
                                                                Ignored when eventCode
                                                                 has other values.
description..........................  N/A....................  Ignoring...............  CMAC--text--alert--mess
                                                                                          age.
N/A..................................  ASCII 7-bit............  Ignoring...............  CMAC--text--encoding.
N/A..................................  Less than 90 characters  Generated by the Alert   CMAC--text--message--le
                                                                 Gateway.                 ngth.
N/A..................................  .......................  Generated by the Alert   CMAC--text--alert--mess
                                                                 Gateway as specified     age.
                                                                 in Section 5.5.
instruction..........................  N/A....................  Ignored................  N/A.
web..................................  .......................  Mapped to a local link   CMAC--web--link.
                                                                 on the Alert Gateway.
contact..............................  N/A....................  Ignored................  N/A.
parameter............................  N/A....................  Passed conditionally     CMAC--text--alert--mess
                                                                 when eventCode=          age.
                                                                 ``EAN'' or ``CAE'';.
                                                                Passed conditionally
                                                                 when eventCode has
                                                                 other values and
                                                                 parameter valueName =
                                                                 ``CMAMtext''; Ignored
                                                                 otherwise.
resource.............................  N/A....................  Ignored................  N/A.
resourceDesc.........................  .......................  Mapped.................  CMAC--resource--descrip
                                                                                          tion.
mimeType.............................  .......................  Mapped.................  CMAC--mime--type.
size.................................  .......................  Mapped.................  CMAC--resource--size.
uri..................................  .......................  Mapped to a local link   CMAC--uri.
                                                                 on the Alert Gateway.
derefUri.............................  N/A....................  Ignored................  N/A.
degest...............................  .......................  .......................  Ignored
area.................................  N/A....................  Ignored................  N/A.
areaDesc.............................  .......................  Passed.................  CMAC--area--description
                                                                                          .
polygon..............................  .......................  Passed.................  CMAC--polygon.
circle...............................  .......................  Passed.................  CMAC--circle.
geocode..............................  .......................  Passed, or generated     CMAC--cmas--geocode.
                                                                 based on polygon and/
                                                                 or circle.
geocode..............................  .......................  Generated based on       CMAC--cmas--gnis.
                                                                 polygon and/or circle.
altitude.............................  N/A....................  Ignored................  N/A.
ceiling..............................  N/A....................  Ignored................  N/A.
----------------------------------------------------------------------------------------------------------------

    29. If an incoming CAP message fails the Alert Gateway 
validation or filtering rules, an error message will be sent over 
the ``B'' interface to the alert originator. The error message may 
contain additional information in the ``note'' element. The ``note'' 
element in the error response to the alert originator may contain 
multiple error messages. The following are some examples of error 
responses.
    a. CMA error 1: Unsupported code value of ``'' 
in element ``'' (e.g. scope = ``Private'')
    b. CMA error 2: Missing required element ``'' (e.g. element Y = eventCode)
    c. CMA error 3: Unsupported element ``'' 
(e.g. element Z = restriction)
    d. CMA error 4: Text message length exceeds maximum 
limit.

10.4 Reference Point C Protocol

    The C reference point is the interface from the Alert Gateway to 
the CMSP Gateway. The C reference point is used to map the CAP 
elements into the CMSP protocol on the C reference point (``CMAC''), 
as follows:

[[Page 596]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.016

10.4.1 Structure of the CMA ``C'' Reference Point Protocol

    The CMSAAC recommends that each CMAC Alert message consist of 
the following segments:

--CMAC Alert Attributes segment
--CMAC Alert Info segment
--CMAC Alert Area segment
--CMAC Alert Resource segment

 The CMSAAC recommends that the
    CMAC Alert Message document object model be as follows:

[[Page 597]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.017

BILLING CODE: 6712-01-C
    The CMSAAC recommends that a CMAC Alert Message must contain:

 one CMAC--Alert--Attributes segment
 one or more CMAC--Alert--Info segments
 one or more CMAC--Alert--Area segements.

    The CMAC--Resource segment is optional for future use in 
streaming audio, streaming video, and multimedia CMAs.

10.4.2 CMAC Data Dictionary

10.4.2.1 CMAC--Alert--Attributes Segment

                                  Table 10-2.--CMAC--Alert--Attributes Segment
----------------------------------------------------------------------------------------------------------------
                                              Mandatory/optional/
              CMAC element                        conditional                       CMAC definition
----------------------------------------------------------------------------------------------------------------
CMAC--alert.............................  M..........................  (1) Surrounds CMAC alert message
                                                                        subelements.
                                                                       (2) MUST include the xmlns attribute
                                                                        referencing the CMAC URN as the
                                                                        namespace, e.g.:  [sub-elements] 
                                                                       (3) In addition to the specified
                                                                        subelements, MAY contain one or more
                                                                         blocks.
CMAC--protocol-- version................  M..........................  The version of the CMAC protocol. Used by
                                                                        the CMSP Gateway only. Specified by the
                                                                        Alert Gateway.
CMAC--sending-- alert--gateway-- id.....  M..........................  URI of the Alert Gateway sending the CMAC
                                                                        message. Specified by thet Alert
                                                                        Gateway.
CMAC--message-- identifier..............  M..........................  A 2-octet binary value uniquely
                                                                        identifying this message, assigned by
                                                                        the Alert Gateway and derived from the
                                                                        CAP identifier element. This element is
                                                                        sent to the mobile device.

[[Page 598]]

 
CMAC--referenced--message--identifier...  C..........................  A 2-octet binary value uniquely
                                                                        identifying a referenced CMAM, assigned
                                                                        by the Alert Gateway. Required for an
                                                                        Update, Cancel or Ack CMAC--message--
                                                                        type. Derived from the CAP references
                                                                        element.
CMAC--special--handling.................  O..........................  Specifies if this alert message requires
                                                                        special handling. Specified by the Alert
                                                                        Gateway, derived from CAP elements.
                                                                       Code Values: ``Presidential'' ``Child
                                                                        Abduction'' ``No Special Handling.''
CMAC--sender............................  M..........................  Identifies the originator of this alert.
                                                                        Used by the CMSP for logging purposes
                                                                        only. Alert Gateway uses the CAP sender
                                                                        element to populate this element.
CMAC--sent--date--time..................  M..........................  The date and time the message is sent by
                                                                        originator in UTC in XML dateTime
                                                                        format. Derived from the CAP sent
                                                                        element.
CMAC--status............................  M..........................  Alert Gateway uses the CAP status element
                                                                        to populate this element. Code Values:
                                                                       ``Actual''--Actionable by all targeted
                                                                        recipients.
                                                                       ``Exercise''--Actionable only by
                                                                        designated exercise participants, for
                                                                        CMSP use.
                                                                       ``System''--For messages that support
                                                                        alert network internal functions. In
                                                                        addition this is used for the ``keep
                                                                        alive'' message between the Alert
                                                                        Gateway and the CMSP Gateway.
                                                                       ``Test''--Technical testing of the C
                                                                        Reference Point only, for CMSP Gateway
                                                                        use only.
CMAC--message--type.....................  M..........................  Alert Gateway uses the CAP msgType
                                                                        element to populate this element. Code
                                                                        Values:
                                                                       ``Alert''--Initial information requiring
                                                                        attention by targeted recipients.
                                                                       ``Update''--Updates and supercedes the
                                                                        earlier message(s) identified in 
                                                                       ``Cancel''--Cancels the earlier
                                                                        message(s) identified in 
                                                                       ``Ack''--Acknowledges receipt and
                                                                        acceptance of the message(s) identified
                                                                        in < CMAC--referenced--message--
                                                                        identifier > additional explanation may
                                                                        appear in 
                                                                       ``Error'' indicates rejection of the
                                                                        message(s) identified in explanation SHOULD appear in 
CMAC--note..............................  O..........................  Optional element. Used for CMSP logging
                                                                        purposes for a cancel or error message
                                                                        type, or to provide a response back to
                                                                        the Alert Gateway. Alert Gateway uses
                                                                        the CAP note element to populate this
                                                                        element on messages from the Alert
                                                                        Gateway to the CMSP Gateway. The CMSP
                                                                        Gateway uses this element on messages to
                                                                        the Alert Gateway.
CMAC--original--cap--alert--uri.........  M..........................  This element contains the uri where the
                                                                        CMSP may retrieve the original complete
                                                                        CAP version of the alert from the Alert
                                                                        Gateway. Specified by the Alert Gateway.
----------------------------------------------------------------------------------------------------------------

10.4.2.2 CMAC--Alert--Info Segment

    Multiple occurrences are permitted within the CAP from the alert 
originator; the CMSAAC recommends that each occurrence be a separate 
CMAM from the Alert Gateway. The CMSAAC further recommends that each 
language be sent as a separate CMAM with a unique message 
identifier. It is anticipated that a separate CMAS--Alert--Info 
element with associated sub-elements will be created for the CMAMs 
to be given to the CMSPs for broadcast via the CMSP selected 
technologies consistent with the requirements and procedures defined 
by the CMSAAC.

                                     Table 10-3.--CMAC--Alert--Info Segment
----------------------------------------------------------------------------------------------------------------
                                              Mandatory/ optional/
              CMAC element                        conditional                       CMAC definition
----------------------------------------------------------------------------------------------------------------
CMAC--alert--info.......................                               (1) Only a single occurrence is permitted
                                                                        within a single . If there
                                                                        are multiple ``info'' segements in the
                                                                        original CAP message, the Alert Gateway
                                                                        shall format as separate CMAC messages
                                                                        each with a unique identifier.
                                                                       (2) In addition to the specified
                                                                        subelements, MAY contain one or more
                                                                         blocks and/or one or
                                                                        more  blocks.
CMAC--category..........................  M..........................  Alert Gateway uses the CAP category
                                                                        element to populate this element. Code
                                                                        Values used by CMSP Gateway only:
                                                                       ``Geo''--Geophysical (inc. landslide).
                                                                       ``Met''--Meteorological (inc. flood).
                                                                       ``Safety''--General emergency and public
                                                                        safety.
                                                                       ``Security''--Law enforcement, military,
                                                                        homeland and local/private security.
                                                                       ``Rescue''--Rescue and recovery.
                                                                       ``Fire''--Fire suppression and rescue.
                                                                       ``Health''--Medical and public health.
                                                                       ``Env''--Pollution and other
                                                                        environmental.
                                                                       ``Transport''--Public and private
                                                                        transportation.
                                                                       ``Infra''--Utility, telecommunication,
                                                                        other non-transport infrastructure.
                                                                       ``CBRNE''--Chemical, Biological,
                                                                        Radiological, Nuclear or High-Yield
                                                                        Explosive threat or attack.
                                                                       ``Other''--Other events.
CMAC--event--code.......................  O..........................  Alert Gateway uses the CAP eventCode
                                                                        element to populate this element.
                                                                        Optional element used by the CMSP
                                                                        Gateway only.

[[Page 599]]

 
                                                                       A system-specific code for event typing,
                                                                        in the form: ,  valueName,
                                                                        value,  where the content of
                                                                        ``CMAC--valueName'' is a user assigned
                                                                        string designating the domain of the
                                                                        code, and the content of ``value'' is a
                                                                        string (which may represent a number)
                                                                        denoting the value itself (e.g., CMAC--
                                                                        valueName =``SAME'' and value=``TOR'').
                                                                       Values of ``CMAC--valueName'' that are
                                                                        acronyms SHOULD be represented in all
                                                                        capital letters without periods (e.g.,
                                                                        SAME).
                                                                       The following SAME codes are supported in
                                                                        CMAS:
                                                                       [cir] Civil Danger Warning CDW
                                                                       [cir] Civil Emergency Message CEM
                                                                       [cir] Evacuation Immediate EVI
                                                                       [cir] Hazardous Materials Warning HMW
                                                                       [cir] Law Enforcement Warning LEW
                                                                       [cir] Local Area Emergency LAE
                                                                       [cir] Nuclear Power Plant Warning NUW
                                                                       [cir] Radiological Hazard Warning RHW
                                                                       [cir] Shelter in Place Warning SPW
                                                                       [cir] Avalanche Warning AVW
                                                                       [cir] Blizzard Warning BZW
                                                                       [cir] Child Abduction Emergency CAE
                                                                       [cir] Coastal Flood Warning CFW
                                                                       [cir] Dust Storm Warning DSW
                                                                       [cir] Earthquake Warning EQW
                                                                       [cir] Fire Warning FRW
                                                                       [cir] Flash Flood Warning FFW
                                                                       [cir] Flood Warning FLW
                                                                       [cir] High Wind Warning HWW
                                                                       [cir] Hurricane Warning HUW
                                                                       [cir] Severe Thunderstorm Warning SVR
                                                                       [cir] Special Marine Warning SMW
                                                                       [cir] Tornado Warning TOR
                                                                       [cir] Tropical Storm Warning TRW
                                                                       [cir] Tsunami Warning TSW
                                                                       [cir] Volcano Warning VOW
                                                                       [cir] Winter Storm Warning WSW
CMAC--response--type....................  O..........................  Alert Gateway uses the CAP responseType
                                                                        element to populate this element. Code
                                                                        values:
                                                                       ``Shelter''--Take shelter in place.
                                                                       ``Evacuate''--Relocate.
                                                                       ``Prepare''--Make preparations.
                                                                       ``Execute''--Execute a pre-planned
                                                                        activity.
                                                                       ``Monitor''--Attend to information
                                                                        sources.
                                                                       ``Assess''--Evaluate the information in
                                                                        this message. (This value SHOULD NOT be
                                                                        used in public warning applications.).
                                                                       ``None''--No action recommended.
                                                                       Multiple instances MAY occur within a
                                                                        single  block. This element
                                                                        is passed to the mobile device.
CMAC--severity..........................  M..........................  Alert Gateway uses the CAP severity
                                                                        element to populate this element. Code
                                                                        Values sent to the mobile device:
                                                                       ``Extreme''--Extraordinary threat to life
                                                                        or property.
                                                                       ``Severe''--Significant threat to life or
                                                                        property.
CMAC--urgency...........................  M..........................  Alert Gateway uses the CAP urgency
                                                                        element to populate this element. Code
                                                                        Values sent to the mobile device:
                                                                       ``Immediate''--Responsive action SHOULD
                                                                        be taken immediately.
                                                                       ``Expected''--Responsive action SHOULD be
                                                                        taken soon (within next hour).
CMAC--certainty.........................  M..........................  Alert Gateway uses the CAP certainty
                                                                        element to populate this element. Code
                                                                        Values sent to the mobile device:
                                                                       ``Observed''--Determined to have occurred
                                                                        or to be ongoing.
                                                                       ````Likely''--Likely (probability > 50%).
CMAC--expires--date--time...............  M..........................  The expiry time of the information of the
                                                                        alert message for use by the CMSP
                                                                        Gateway. The date and time is
                                                                        represented in UTC [dateTime] format.
                                                                        Maximum duration is 24 hours. Derived
                                                                        from the CAP expires element.
CMAC--sender--name......................  O..........................  Optional element for logging purposes at
                                                                        the CMSP Gateway. The human-readable
                                                                        name of the agency or authority issuing
                                                                        this alert. Alert Gateway uses the CAP
                                                                        senderName element to populate this
                                                                        element.
CMAC--text--language....................  M..........................  Specifies the language of the text in the
                                                                        CMAC--text--alert--message, for use by
                                                                        the mobile device.
                                                                       Code Values: ``English'', ``Spanish'',
                                                                        ``French'' (future Canada use only),
                                                                        ``Other''--for future use.
                                                                       Specified by the Alert Gateway and
                                                                        derived from the CAP language element.

[[Page 600]]

 
CMAC--text--encoding....................  M..........................  Specifies the data encoding scheme of the
                                                                        text in the CMAC--text--alert--message,
                                                                        for use by the mobile device.
                                                                       Code Values: ``UTF-8''.
                                                                       Specified by the Alert Gateway.
CMAC--text--alert--message--length......  M..........................  The length, in characters, of the text in
                                                                        the CMAC--text--alert--message. Note the
                                                                        number of octets in the CMAC--text--
                                                                        alert--message can be derived from this
                                                                        parameter and the CMAC--text--encoding
                                                                        parameter. Specified by the Alert
                                                                        Gateway.
CMAC--text--alert--message..............  M..........................  The text of the alert message for use by
                                                                        the mobile device. This field is defined
                                                                        by the CMAS Text Profile and may contain
                                                                        up to 90 English characters using a 7-
                                                                        bit encoding scheme. Other languages or
                                                                        data encoding schemes will change the
                                                                        number of characters supported.
                                                                        Specified by the Alert Gateway, which
                                                                        may be derived or obtained via CAP
                                                                        elements.
CMAC--web--link.........................  O..........................  Optional element for future use. The
                                                                        identifier of the hyperlink associating
                                                                        additional information with the alert
                                                                        message. This data must be in a domain
                                                                        accessible by the CMSP Gateway. Alert
                                                                        Gateway uses the CAP web element to
                                                                        populate this element.
----------------------------------------------------------------------------------------------------------------

10.4.2.3 CMAC--Area Segment

    Multiple occurrences are permitted.

                                         Table 10-4.--CMAC--Area Segment
----------------------------------------------------------------------------------------------------------------
                                              Mandatory/ optional/
              CMAC element                        conditional                       CMAC definition
----------------------------------------------------------------------------------------------------------------
CMAC--area..............................  M..........................  (1) Multiple occurrences permitted, in
                                                                        which case the target area for the
                                                                         block is the union
                                                                        of all the included  blocks.
                                                                       (2) MAY contain one or multiple instances
                                                                        of  or ,
                                                                        and shall contain at least one instance
                                                                        of . If multiple ,  or  elements are included, the area
                                                                        described by this  is the union of
                                                                        those represented by the included
                                                                        elements.
CMAC--area--description.................  M..........................  The text describing the affected area of
                                                                        the alert message for use by the CMSP
                                                                        for logging purposes only. Alert Gateway
                                                                        uses the CAP areaDesc element to
                                                                        populate this element.
CMAC--polygon...........................  O..........................  Optional element. The paired values of
                                                                        points defining a polygon that
                                                                        delineates the affected area of the
                                                                        alert message. Alert Gateway uses the
                                                                        CAP polygon element to populate this
                                                                        element.
CMAC--circle............................  O..........................  Optional element. The paired values of a
                                                                        point and radius delineating the
                                                                        affected area of the alert message.
                                                                        Alert Gateway uses the CAP circle
                                                                        element to populate this element.
CMAC--cmas--geocode.....................  M..........................  The CMAS-defined geographic code
                                                                        delineating the affected area of the
                                                                        alert message. This is an extension to
                                                                        the FIPS code (see Section 10.4.5).
                                                                        Alert Gateway uses the CAP geocode,
                                                                        polygon, circle, and/or sender elements
                                                                        to derive this element.
CMSC--gnis..............................  O..........................  Optional element. This value is the
                                                                        geographic code delineating the affected
                                                                        area of the alert message using the
                                                                        U.S.G.S. Geographic Names Information
                                                                        System (GNIS) code. Derived by the Alert
                                                                        Gateway.
----------------------------------------------------------------------------------------------------------------

10.4.2.4 CMAC--Resource Segment

    Multiple occurrences are permitted. The CMAC--Resource segment 
is not used for the Text Profile but may be applicable to future 
streaming audio, streaming video, and multimedia alerts.

                                      Table 10-5.--CMAC-- Resource Segment
----------------------------------------------------------------------------------------------------------------
                                              Mandatory/optional/
              CMAC element                        conditional                       CMAC definition
----------------------------------------------------------------------------------------------------------------
CMAC--resource..........................  O..........................  (1) Refers to an additional file with
                                                                        supplemental information related to this
                                                                         element; e.g., an
                                                                        image or audio file.
                                                                       (2) Multiple occurrences MAY occur within
                                                                        a single  block.
CMAC--resource--description.............  O..........................  Optional element. The human-readable text
                                                                        describing the content and kind, such as
                                                                        ``map'' or ``photo,'' of the resource
                                                                        file. For use by the CMSP Gateway for
                                                                        logging purposes only. Alert Gateway
                                                                        uses the CAP resourceDesc element to
                                                                        populate this element.
CMAC--mime--type........................  O..........................  Optional element. The identifier of the
                                                                        MIME content type and sub-type
                                                                        describing the resource file. Alert
                                                                        Gateway uses the CAP mimeType element to
                                                                        populate this element.
CMAC--resource--size....................  O..........................  Optional element. The integer indicating
                                                                        the size of the resource file. Alert
                                                                        Gateway uses the CAP size element to
                                                                        populate this element.
CMAC--resource--uri.....................  O..........................  Optional element. The identifier of the
                                                                        hyperlink for the resource file. Alert
                                                                        Gateway uses the CAP uri element to
                                                                        populate this element.

[[Page 601]]

 
CMAC--digest............................  O..........................  Optional element. The code representing
                                                                        the digital digest (``hash'') computed
                                                                        from the resource file. Calculated using
                                                                        the Secure Hash Algorithm (SHA-1) per
                                                                        [FIPS 180-2]. Alert Gateway uses the CAP
                                                                        digest element to populate this element.
----------------------------------------------------------------------------------------------------------------

10.4.3 Example CMAC XML Schema





CMAC Alert Message (version 1.0)
















































































































































[[Page 602]]



















10.4.4 Element Mapping From B Reference Point (CAP) to C Reference 
Point (CMAC) to E Reference Point (CMAE) Elements

    Note: elements listed in bold are mandatory.


  Table 10-6.--Mapping Reference Point B Elements to Reference Point C
                                Elements
------------------------------------------------------------------------
           CAP element               CMAC element        CMAE element
------------------------------------------------------------------------
N/A.............................  CMAC--protocol--ve  N/A.
                                   rsion.
N/A.............................  N/A...............  CMAE--protocol--ve
                                                       rsion.
N/A.............................  CMAC--sending--ale  N/A.
                                   rt--gateway--id.
identifier......................  CMAC--message--ide  CMAE--identifier.
                                   ntifier.
references......................  CMAC--referenced--  N/A.
                                   message--identifi
                                   er.
N/A.............................  CMAC--special--han  CMAE--alert--handl
                                   dling.              ing.
sender..........................  CMAC--sender......  N/A.
sent............................  CMAC--sent--date--  N/A.
                                   time.
status..........................   CMAC--status.....  N/A.
msgType.........................  CMAC--message--typ  CMAE--alert--type.
                                   e.
source..........................  N/A...............  N/A.
scope...........................  N/A...............  N/A.
restriction.....................  N/A...............  N/A.
code............................  N/A...............  N/A.
note............................  CMAC-- note.......  N/A.
incidents.......................  N/A...............  N/A.
N/A.............................  CMAC--original--ca  N/A.
                                   p--alert--uri.
category........................  CMAC--category....  CMAE--category.
event...........................  N/A...............  N/A.
eventCode.......................  CMAC--event--code.  N/A.
responseType....................  CMAC--response--ty  CMAE--response--ty
                                   pe.                 pe.
severity........................  CMAC--severity....  CMAE--severity.
urgency.........................  CMAC--urgency.....  CMAE--urgency.
certainty.......................  CMAC--certainty...  CMAE--certainty.
audience........................  N/A...............  N/A.
effective.......................  N/A...............  N/A.
onset...........................  N/A...............  N/A.
expires.........................  CMAC--expires--dat  CMAE--expires.
                                   e--time.
senderName......................  CMAC--sender--name  N/A.
language........................  CMAC--text--langua  CMAE--language.
                                   ge.
N/A.............................  CMAC--text--encodi  CMAE--char--set.
                                   ng.
N/A.............................  CMAC--text--alert-  CMAE--alert--text-
                                   -message--length.   -length.
parameter (when value = ``CMAM    CMAC--text--alert-  CMAE--alert--text.
 text'').                          -message.
headline........................  N/A...............  N/A.
description.....................  N/A...............  N/A.
instruction.....................  N/A...............  N/A.
web.............................  CMAC--web--link...  N/A.
contact.........................  N/A...............  N/A.
parameter (when value not =       N/A...............  N/A.
 ``CMAMtext'').
areaDesc........................  CMAC--area--descri  N/A.
                                   ption.
polygon.........................  CMAC--polygon.....  N/A.
circle..........................  CMAC--circle......  N/A.
geocode.........................  CMAC--cmas--geocod  N/A.
                                   e.
geocode.........................  CMSC--gnis........  N/A.
altitude........................  N/A...............  N/A.
ceiling.........................  N/A...............  N/A.
resourceDesc....................  CMAC--resource--de  N/A.
                                   scription.
mimeType........................  CMAC--mime--type..  N/A.
size............................  CMAC--resource--si  N/A.
                                   ze.
uri.............................  CMAC--resource--ur  N/A.
                                   i.
derefUri........................  N/A...............  N/A.
digest..........................  CMAC--digest......  N/A.
N/A.............................  N/A...............  CMAE--associated--
                                                       multimedia--indic
                                                       ator.
N/A.............................  N/A...............  CMAE--CMSP--define
                                                       d--parameter.
N/A.............................  N/A...............  CMAE--reserved.
------------------------------------------------------------------------


[[Page 603]]

10.4.5 Definition of CMAC--cmas--geocode Element

    The CMAC--cmas--geocode is five characters where the first two 
characters or digits identify the state or region and the last three 
digits identify the specific counties, regions, or equivalent 
entities. The CMSAAC recommends that the CMAC--cmas--geocode be 
assigned as follows:
    1. The CMAC--cmas--geocode indication for a specific county will 
be as defined in Federal Information Processing Standard 6-4 (FIPS 
6-4), titled ``Counties and Equivalent Entities of the United 
States, Its Possessions, and Associated Areas'', dated 31 August 
1990.
    2. The CMAC--cmas--geocode indication for an entire state will 
be the two digit FIPS State Numeric Code as defined in Federal 
Information Processing Standard 5-2 (FIPS 5-2), titled ``Codes for 
the Identification of the States, the District of Columbia and the 
Outlying Areas of the United States, and Associated Areas'', dated 
28 May 1987 followed by three zeroes (000).
    3. The CMAC--cmas--geocode indication for an entire United 
States including all states, the District of Columbia, possessions, 
and associated areas will be US000.
    4. In the future, it is possible that alerts may be targeted for 
regions of the country (e.g., Gulf States). The more efficient and 
error resistant solution would be to have CMAC--cmas--geocode values 
for regional areas such as FEMA regions or National Weather Service 
(NWS) regions. The FEMA regions would be assigned values in the 
format of US0xx and the NWS regions would be assigned values in the 
format of US1xx.
    The following table defines the CMAC--cmas--geocode value 
assignments.

              Table 10-7.--CMAC--cmas--geocode Assignments
------------------------------------------------------------------------
        CMAC--cmas geocode                       Definition
------------------------------------------------------------------------
00000.............................  Not used.
00001 thru 99999..................  For identification of states and
                                     counties.
US000.............................  Entire United States.
US001.............................  FEMA Region 1 (Maine, Vermont, New
                                     Hampshire, Rhode Island,
                                     Massachusetts, and Connecticut).
US002.............................  FEMA Region 2 (New York, New Jersey,
                                     Puerto Rico, and Virgin Islands).
US003.............................  FEMA Region 3 (Delaware, District of
                                     Columbia, Maryland, Pennsylvania,
                                     Virginia, and West Virginia).
US004.............................  FEMA Region 4 (Alabama, Florida,
                                     Georgia, North Carolina, South
                                     Carolina, Tennessee, Kentucky, and
                                     Mississippi).
US005.............................  FEMA Region 5 (Illinois, Indiana,
                                     Michigan, Minnesota, Ohio, and
                                     Wisconsin).
US006.............................  FEMA Region 6 (Arkansas, Louisiana,
                                     New Mexico, Oklahoma, and Texas).
US007.............................  FEMA Region 7 (Iowa, Kansas,
                                     Missouri, and Nebraska).
US008.............................  FEMA Region 8 (Colorado, Montana,
                                     North Dakota, South Dakota, and
                                     Utah).
US009.............................  FEMA Region 9 (Arizona, California,
                                     Hawaii, Nevada, American Samoa,
                                     Guam, Commonwealth of the Northern
                                     Mariana Islands, Republic of the
                                     Marshall Islands, and Federated
                                     States of Micronesia).
US010.............................  FEMA Region 10 (Alaska, Idaho,
                                     Oregon, and Washington).
US011 thru US100..................  Not Assigned.
US101.............................  National Weather Service (NWS)
                                     Central Region (Colorado, Illinois,
                                     Indiana, Iowa, Kansas, Kentucky,
                                     Michigan, Minnesota, Missouri, and
                                     Nebraska).
US102.............................  National Weather Service (NWS)
                                     Eastern Region (Maine, Maryland,
                                     Massachusetts, New Jersey, New
                                     York, North Carolina, Ohio,
                                     Pennsylvania, South Carolina, and
                                     Vermont).
US103.............................  National Weather Service (NWS)
                                     Southern Region (Alabama, Arkansas,
                                     Florida, Georgia, Louisiana,
                                     Mississippi, New Mexico, Oklahoma,
                                     Puerto Rico, Tennessee, and Texas).
US104.............................  National Weather Service (NWS)
                                     Western Region (Arizona,
                                     California, Idaho, Montana, Nevada,
                                     Oregon, Utah, and Washington).
US105.............................  National Weather Service (NWS)
                                     Alaska Region (Alaska).
US106.............................  National Weather Service (NWS)
                                     Pacific Region (Hawaii, Guam,
                                     America Samoa).
US107 thru US999..................  Not Assigned.
------------------------------------------------------------------------

10.4.6 Definition of CMAC Response Codes

    The CMSAAC recommends the following as the response codes that 
may be returned from the CMSP Gateway to the Alert Gateway in the 
CMAC--note element in response a received CMAS message via the 
Reference Point C interface:

CMAC--Error--100 Invalid Alert Gateway ID
CMAC--Error--101 Unsupported protocol version
CMAC--Error--102 Segment XXX missing
CMAC--Error--103 Invalid message length
CMAC--Error--104 Mandatory element XXX missing
CMAC--Error--105 Conditional element XXX missing which is required 
based upon value of element YYYY
CMAC--Error--106 Optional element XXX not allowed
CMAC--Error--107 Unrecognized value in element XXX
CMAC--Error--108 Value in element XXX is out of acceptable range
CMAC--Error--109 Value XXX of element YYY not supported
CMAC--Error--110 Invalid length of element XXX
CMAC--Error--111 Expiration time greater than allowed interval
CMAC--Error--112 Failure to convert text message into alphabet 
encoding scheme
CMAC--Error--113 Text encoding not compatible with specified text 
language
CMAC--Error--114 Special handling element not consistent with 
message content
CMAC--Error--115 Polygon element contains more than maximum number 
of coordinates
CMAC--Error--200 Failure to retrieve additional alert info from 
Alert Gateway
CMAC--Error--201 Message received after expiration time
CMAC--Error--203 Message update failed
CMAC--Error--204 Message cancellation failed
CMAC--Error--300 Alert message failed due to insufficient system 
storage
CMAC--Error--301 CMSP server error
CMAC--Error--302 Maximum number of sessions reached (if C interface 
is session based)
CMAC--Resp--400 CMAS test successful
CMAC--Resp--401 CMAS test failed due to XXX
CMAC--Resp--500 Transient error on CMSP Gateway--Discontinue 
transmission of alerts
CMAC--Resp--501 Resume transmission of alerts to CMSP Gateway
CMAC--Resp--502 Keep alive message response

10.4.7 Example CMAS ``C'' Interface Alert Messages

As an example of a CMAS Alert Message, consider the following CAP 
alert message from the National Weather Service:
    
    NOAA-NWS-ALERTS Arizona 2007-08-01T18:22:17-
04:00
    [email protected]
    2007-08-01T18:22:17-04:00
    Actual
    Alert
    Public

[[Page 604]]

    Current Watches, Warnings and Advisories for Arizona 
Issued by the National Weather Service
    http://www.weather.gov/alerts/az.html 
    
    Met
    Flash Flood Warning 
    Expected 
    Severe
    Likely
    2007-08- 01T22:11:00
    2007-08-01T23:15:00 
    Flash Flood Warning
    FLASH FLOOD WARNING AZC005-012315--BULLETIN--
EAS ACTIVATION REQUESTED FLASH FLOOD WARNING NATIONAL WEATHER 
SERVICE FLAGSTAFF AZ 311 PM MST WED AUG 1 2007 THE NATIONAL WEATHER 
SERVICE IN FLAGSTAFF HAS ISSUED A * FLASH FLOOD WARNING FOR... SOUTH 
CENTRAL COCONINO COUNTY IN NORTH CENTRAL ARIZONA... * UNTIL 415 PM 
MST * AT 306 PM MST...NATIONAL WEATHER SERVICE DOPPLER RADAR 
INDICATED FLASH FLOODING FROM A THUNDERSTORM OVER THE WARNED AREA. * 
LOCATIONS IN THE WARNING INCLUDE HIGHWAY 89 THROUGH OAK CREEK CANYON 
BETWEEN SLIDE ROCK STATE PARK AND MIDGELY BRIDGE. THE HEAVY RAINS 
WILL LIKELY TRIGGER LIFE-THREATENING ROCKSLIDES... MUDSLIDES...AND 
DEBRIS FLOWS NEAR THE BRINS FIRE BURN AREA IN OAK CREEK CANYON...AS 
WELL AS FLOODING OF CREEKS...ROADS...AND NORMALLY DRY WASHES. DO NO 
ATTEMPT TO DRIVE THROUGH THIS AREA UNTIL THE THREAT HAS DIMINISHED. 
LAT...LON 3488 11177 3489 11169 3499 11169 3498 11177 $$ DB 
    http://www.weather.gov/alerts/
AZ.htmlAZC005.FGZFFWFGZ.221100
    
    Kaibab Plateau, Marble, Glen Canyons, Grand Canyon 
Country, Coconino Plateau, Northeast Plateaus, Mesas Hwy, Little 
Colorado River Valley in, Western Mogollon Rim, Eastern Mogollon 
Rim, Oak Creek, Sycamore Canyons, Northeast Plateaus, Mesas Sou 
(Arizona) 
    004005
    
    
    
    This Alert Gateway would construct a CMAS ``C'' Interface 
message based on this CAP alert as follows:
    
    
    1.0 
    http://cmas_alert_gateway.gov 
    1056
     [email protected] 
    2003-06-17T14:57:00-07:00 
    Actual 
    Alert 
    http://cmas_alert_gateway.gov/CMAM1056 
    
    Met 
    Severe 
    Expected 
    Likely 
    2007-08-01T23:15:00
    English 
    ISO-6739-2
    56 
    Severe Weather Warning until 4:15pm MST 
    
    Kaibab Plateau, Marble, Glen Canyons, 
Grand Canyon Country, Coconino Plateau, Northeast Plateaus, Mesas 
Hwy, Little Colorado River Valley in, Western Mogollon Rim, Eastern 
Mogollon Rim, Oak Creek, Sycamore Canyons, Northeast Plateaus, Mesas 
Sou (Arizona) 
    004005 
    
    
    

This CMAM would be broadcast as:
    Severe Weather Warning in this area until 4:15pm MST NWS

10.5 Reference Point E Protocols

    The protocols that will be used for Reference Point E are 
dependent upon the capabilities of the delivery technology or 
technologies that have been selected by the CMSP.
    The following is the CMA specific information that must be 
delivered over Reference Point ``E'' to support the CMAS text 
profile; mapping of this information to the delivery technology is 
beyond the scope of the CMSAAC:

            Table 10-8.--Reference Point E Protocol Elements
------------------------------------------------------------------------
             Parameter                            Function
------------------------------------------------------------------------
CMAE--protocol--version...........  CMAE protocol version.
CMAE--identifier..................  A number uniquely identifying this
                                     message.
CMAE--alert--handling.............  Identifies special handling for the
                                     alert:
                                    --Presidential Alert.
                                    --Child Abduction Emergency (i.e.,
                                     AMBER Alert)
                                    Additional values are reserved for
                                     future use.
CMAE--alert--type.................  Alert message is new, update or
                                     cancel CMAS alert.
CMAE--language....................  Language of the alert message in the
                                     CMAE--Alert--Text parameter.
CMAE--char--set...................  Character set for the alert message
                                     in the CMAE--Alert--Text parameter
                                     (e.g., GSM 7-bit encoding, ISO 639-
                                     2, UCS-2, UTF-16).
------------------------------------------------------------------------

11 Annex A--Anticipated Peak & Average CMAS Traffic Volume

    In 2006, there was a total of 9239 tornado and flash flood 
warnings in the U.S. as reported by the National Weather Service. 
The following has a breakdown by state of these warnings:

[[Page 605]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.018

    It can be assumed that these warnings account for approximately 
50% of all warnings issued in 2006. In addition, there are 
approximately 1200 child abduction emergency/Amber Alerts per year.
    Given the above statistics and adding a factor of uncertainty 
in, the anticipated initial yearly CMAMs for a single language of 
English which meet the criteria for CMAs is assumed to be 25,000 
alerts per year. This number is expected to grow due to increased 
usage and due to the potential support of additional languages in 
the future.
    On a monthly basis, the tornado and flash flood data is as 
follows:

[[Page 606]]

[GRAPHIC] [TIFF OMITTED] TP03JA08.019

    Using these actual alert statistics as a percent of the total 
per month, and applying to the 25,000 estimate number yields the 
following estimate of alerts per month:

               Table 11-3.--Estimated CMA Volume by Month
------------------------------------------------------------------------
 
------------------------------------------------------------------------
CMA Estimate Per Month:
  January....................................................        658
  February...................................................        273
  March......................................................       3158
  April......................................................       3123
  May........................................................       2695
  June.......................................................       3802
  July.......................................................       3001
  August.....................................................       2473
  September..................................................       2535
  October....................................................       1786
  November...................................................       1050
  December...................................................        446
                                                              ----------
    Total....................................................      25000
------------------------------------------------------------------------

    Note there is significant uncertainty in these estimates as one 
cannot predict ``mother nature'' or human activities. These 
estimates should only serve as guidelines to the anticipated message 
traffic in the CMAS.

12 Annex B--WARN Act Statutory Requirements

12.1 WARN Act Requirements

    1. Transmission of emergency alerts via commercial mobile 
service is voluntary.
    a. Commercial mobile service operators may voluntarily elect to 
transmit emergency alerts {Sec. 602(a){time} .
    2. A commercial mobile service operator who elects to transmit 
emergency alerts agree to do so in a manner consistent with the 
technical standards, protocols, procedures, and other technical 
requirements implemented by the Commission.\17\
---------------------------------------------------------------------------

    \17\ WARN Act, Sec.  602(b)(2)(B)(ii).
---------------------------------------------------------------------------

    3. A commercial mobile service operator who elects to transmit 
emergency alerts can elect to transmit the emergency alert services 
in whole or in part.\18\
---------------------------------------------------------------------------

    \18\ WARN Act, Sec.  602(b)(1)(B). The Committee interprets the 
definition of ``in whole or in part'' to include the following: All 
or a subset of the mobile operator's service area and/or all or a 
subset of current and future mobile devices supported by the mobile 
operator network.
---------------------------------------------------------------------------

    4. A commercial mobile service operator who elects in whole or 
in part NOT to transmit emergency alerts:
    a. Must provide clear and conspicuous notice at 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.\19\
---------------------------------------------------------------------------

    \19\ Id. Sec.  602(b)(1)(B).
---------------------------------------------------------------------------

    b. Must provide notification of this decision to its existing 
subscribers.\20\
---------------------------------------------------------------------------

    \20\ Id. Sec.  602(b)(1)(C).
---------------------------------------------------------------------------

    c. Shall not by itself provide a basis for liability against the 
provider (including its officers, directors, employees, vendors, and 
agents).\21\
---------------------------------------------------------------------------

    \21\ Id. Sec.  602(e)(2).
---------------------------------------------------------------------------

    5. Commercial mobile service licensee may not impose a separate 
or additional charge for such transmission or capability.\22\
---------------------------------------------------------------------------

    \22\ Id. Sec.  602(b)(2)(C).
---------------------------------------------------------------------------

    6. 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.\23\
---------------------------------------------------------------------------

    \23\ Id. Sec.  602.(b)(2)(E) & Sec. 603(c)(5).
---------------------------------------------------------------------------

    7. CMSPs who elect to transmit emergency alerts may transmit in 
languages in addition to English to the extent practical and 
feasible.\24\
---------------------------------------------------------------------------

    \24\ Id. Sec.  603(c)(4){time} .
---------------------------------------------------------------------------

    8. Any CMSP (including its officers, directors, employees, 
vendors, and agents) that transmits emergency alerts and meets its 
obligations under this title shall not be liable to any subscriber 
to, or user of, such person's service or equipment for
    a. Any act or omission related to or any harm resulting from the 
transmission of, or failure to transmit, an emergency alert.\25\
---------------------------------------------------------------------------

    \25\ Id. Sec.  6022(e)(1)(A){time} .
---------------------------------------------------------------------------

    b. The release to a government agency or entity, public safety, 
fire service, law enforcement official, emergency medical service, 
or emergency facility of subscriber information used in connection 
with delivering such an alert.\26\
---------------------------------------------------------------------------

    \26\ Id. Sec.  602(e)(1)(B).
---------------------------------------------------------------------------

12.2 WARN Act Interpretations

12.2.1 CMSP Election

    The WARN Act specifies the election process for a CMSP that 
elects to transmit CMAs as follows:

    602(b)(2) ELECTION--
    (A) IN GENERAL--Within 30 days after the Commission issues its 
order under paragraph (1), 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.\27\
---------------------------------------------------------------------------

    \27\ Id. Sec.  602(b)(2).

    The above mentioned election process must be complete in 
September, 2008 as specified in the timelines in the WARN Act.
    The CMAS requires new technology development and deployments, 
including development of mobile device functionality for CMAS and 
new mobile devices. The requirements for this new technology will 
not be available until the completion of the CMSAAC process and the 
completion of the FCC Report and Order in April, 2008 as specified 
by the WARN Act. Typical development cycles for a development of 
this magnitude require up to 12 months of standardization work in 
the appropriate standards bodies once the requirements are finalized 
followed by 18-24 months implementation and deployment before 
availability of the service and supporting mobile devices.
    Thus, a CMSP that files an election with the Commission in 
September 2008 with the intent to transmit emergency alerts is 
making a commitment to support the development and deployment of 
technology for the following:

--``C'' reference point
--CMSP Gateway
--CMSP Infrastructure
--Mobile Device with CMAS functionality and support of the CMSP 
selected technology

    However, the technology, capabilities for deployment, and mobile 
devices may not be

[[Page 607]]

available for initial deployment and subscriber purchase potentially 
12 months plus 18-24 months (approximately 30-36 months) following 
the CMSAAC recommendation, due to the required standardization and 
development cycles for the technology and capabilities of the mobile 
devices. Full deployments may not occur until a much later timeframe 
via a phased implementation.
[GRAPHIC] [TIFF OMITTED] TP03JA08.020

    The above potential deployment timeline is based upon the 
assumptions that (1) the CMSAAC recommendations contained within 
this document are accepted without any major technical changes and 
(2) the government documentation and deliverables are available at 
the milestone dates indicated on the timeline. The industry will 
begin standardization efforts at the completion of the CMSAAC 
recommendations but any major technical changes to the CMSAAC 
recommendations will adversely affect the above potential deployment 
timeline.
    There are factors outside of the CMSP's direct control that will 
influence the deployment and availability of CMA service. These 
factors include manufacturer development cycles for equipment in the 
CMSP infrastructure, manufacturer commitment to support the delivery 
technology of choice by the CMSP, and mobile device manufacturer 
development of the required CMAS functionality on the mobile 
devices. Typically, a CMSP will have equipment from multiple 
manufacturers deployed in the CMSP infrastructure. Multi-vendor 
environments require feature availability and deployment alignment, 
and require interoperability testing between the different 
manufacturers equipment. Also, if a CMSP chooses a particular 
technology to transmit alerts (e.g., cell broadcast), if a vendor 
with which a CMSP has a relationship chooses not to develop the same 
capability, then the CMSP may be forced into not electing to 
transmit alerts (at least not ``in whole'').
    It is also assumed the requirements, development, and 
deployments of the Alert Gateway and Alert Aggregator align with the 
CMSP developments to allow for testing during the development 
process and prior to CMAS deployments.

12.3 Licensees and Permittees of Noncommercial Educations Broadcasting 
Stations or Public Television Stations

    The WARN Act requires in section 602(c) that:

    Within 90 days after the date on which the Commission adopts 
relevant technical standards based on recommendations of the 
Commercial Mobile Service Alert Advisory Committee, established 
pursuant to section 603(a), the Commission shall complete a 
proceeding to require licensees and permittees of noncommercial 
educational broadcast stations or public broadcast stations (as 
those terms are defined in section 397(6) of the Communications Act 
of 1934 (47 U.S.C. 397(6))) to 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 commercial mobile service providers that have 
elected to transmit emergency alerts under this section.\28\
---------------------------------------------------------------------------

    \28\ Id. Sec.  602(c).

    This Committee acknowledges the potential relevance of the 
rulemaking described in section 602(c) of the WARN Act to this 
Committee's recommendations. Accordingly, the Committee recommends 
that the equipment and technologies described in Section 602(c) of 
the WARN Act be deployed promptly and in a manner consistent with 
the Committee's recommendations. The Committee further recommends 
that the national organization representing the licensees and 
permittees of non-commercial broadcast stations work with the FCC 
---------------------------------------------------------------------------
pursuant to Section 602(c) on the necessary equipment.

[FR Doc. E7-24876 Filed 1-2-08; 8:45 am]
BILLING CODE 6712-01-P