[Federal Register: January 3, 2008 (Volume 73, Number 2)]
[Proposed Rules]
[Page 545-607]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr03ja08-17]
[[Page 545]]
-----------------------------------------------------------------------
Part II
Federal Communications Commission
-----------------------------------------------------------------------
47 CFR Chapter I
Commercial Mobile Alert System; Proposed Rule
[[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; FCC504@fcc.gov 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 PRA@fcc.gov and to Nicholas A. Fraser, Office
of Management and Budget, via e-mail to
Nicholas_A._Fraser@omb.eop.gov 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
PRA@fcc.gov 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
fcc@bcpiweb.com. 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 presentat