Commercial Mobile Alert System, 546-607 [E7-24876]
Download as PDF
546
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
FEDERAL COMMUNICATIONS
COMMISSION
47 CFR Chapter I
[PSHSB Docket No. 07–287; FCC 07–214]
Commercial Mobile Alert System
Federal Communications
Commission.
ACTION: Notice of Proposed Rulemaking.
sroberts on PROD1PC70 with PROPOSALS
AGENCY:
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: https://
www.regulations.gov/. Follow the
instructions for submitting comments.
• Federal Communications
Commission’s Web site: https://
www.fcc.gov/cgb/ecfs/. Follow the
instructions for submitting comments.
• People with Disabilities: Contact
the FCC to request reasonable
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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 https://
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;
PO 00000
Frm 00002
Fmt 4701
Sfmt 4702
(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 forprofit.
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00003
Fmt 4701
Sfmt 4702
547
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
E:\FR\FM\03JAP2.SGM
03JAP2
548
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00004
Fmt 4701
Sfmt 4702
(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, pointto-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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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 CAPformatted 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
PO 00000
Frm 00005
Fmt 4701
Sfmt 4702
549
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 geotargeting 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
E:\FR\FM\03JAP2.SGM
03JAP2
550
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00006
Fmt 4701
Sfmt 4702
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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, nonelection, 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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00007
Fmt 4701
Sfmt 4702
551
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
E:\FR\FM\03JAP2.SGM
03JAP2
552
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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 DTVbased 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,
PO 00000
Frm 00008
Fmt 4701
Sfmt 4702
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00009
Fmt 4701
Sfmt 4702
553
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
554
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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,
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00010
Fmt 4701
Sfmt 4702
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 nonGuard 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. Seventytwo 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,
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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-
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00011
Fmt 4701
Sfmt 4702
555
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
556
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00012
Fmt 4701
Sfmt 4702
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
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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.
sroberts on PROD1PC70 with PROPOSALS
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00013
Fmt 4701
Sfmt 4702
557
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
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
558
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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
PO 00000
Frm 00014
Fmt 4701
Sfmt 4702
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.
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
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, § 603(c).
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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)
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 nonPresidential 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
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.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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).
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, geotargeting be at least precise enough to target
at the county level. The CMSAAC further
5 WARN
PO 00000
Act, § 602(c).
Frm 00015
Fmt 4701
Sfmt 4702
559
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 geotargeting.
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 technologyneutral 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
E:\FR\FM\03JAP2.SGM
03JAP2
560
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
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
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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 endto-end architecture for delivery of emergency
alert messages subject to the WARN Act.
Commercial Mobile Service Provider
(CMSP)—Per the WARN Act Section
PO 00000
Frm 00016
Fmt 4701
Sfmt 4702
602(b)(1)(A), a CMSP is a licensee providing
commercial mobile service as defined in
section 332(d)(1) of the Communications Act
of 1934 (47 U.S.C. 332(d)(1)), where the term
‘‘commercial mobile service’’ means any
mobile service that is provided for profit and
makes interconnected service available.6
1.3
Acronyms
AMBER America’s Missing: Broadcast
Emergency Response
CAP Common Alerting Protocol as defined
in CAP version 1.1 specification
CDMA Code Division Multiple Access
CMA Commercial Mobile Alert
CMAM Commercial Mobile Alert Message
CMAS Commercial Mobile Alert Service
CMSAAC Commercial Mobile Service Alert
Advisory 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
6 WARN
E:\FR\FM\03JAP2.SGM
Act, § 602(b)(1)(A).
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
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.
sroberts on PROD1PC70 with PROPOSALS
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.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
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 bidirectional 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 nonrepudiation) the received wireless alert
message.
PO 00000
Frm 00017
Fmt 4701
Sfmt 4702
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.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.000
2.2 Government Administered Elements
Definitions & Requirements
561
562
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
TABLE 2–1.—CMSP PROFILE ON ALERT GATEWAY
Profile parameter
Parameter election
CMSP Name ...........................................
CMSP Gateway Address ........................
Geo-Location Filtering .............................
................................................................
IP address or Domain Name .................
Alternate IP address ..............................
................................................
If yes, list of states ..................................
CMAC Geocode for state ......................
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.
sroberts on PROD1PC70 with PROPOSALS
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.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Description
Unique identification of CMSP.
Optional and subject to implementation.
If ‘‘yes’’ the only CMAM issued in the listed states will be
sent to the CMSP Gateway.
If ‘‘no’’, all CMAM will be sent to the CMSP Gateway.
List can be state name, abbreviated state name, or CMAC
GeoCode for state (see Section 10.4.5).
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, reformatting, 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
PO 00000
Frm 00018
Fmt 4701
Sfmt 4702
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
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
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 optout 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.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
b. Presentation of a CMAS alert will
activate associated visual, audio, and
mechanical (e.g., vibration) indicators per
subscriber options configured on the mobile
device.
7. Detection and suppression of
presentation of duplicate CMAS alerts.
8. Suppression of CMAS alert visual, audio
and mechanical (e.g., vibration) indicators
upon subscriber’s action on the mobile
device user interface (e.g., key stroke, touch
screen).
3
Deployment Scenarios
The WARN Act specifies that a commercial
mobile service operator who elects to
transmit emergency alerts can elect to
transmit the CMAS alerts in whole or in
part.7 The CMSAAC recommends that the
definition of ‘‘in whole or in part’’ include
the following:
• All or a subset of the CMSP’s service
area.
• All or a subset of current and future
mobile devices supported by the CMSP
network.
For reasons detailed in Annex B—WARN
Act Statutory Requirements, the date of
election is likely not the date of deployment.
Therefore the CMSAAC recommends that the
process for a CMSP to ‘‘file an election with
the Commission with respect to whether or
not it intends to transmit emergency alerts’’
should include the following information:
1. Potential date of initial deployment.
7 WARN
PO 00000
Act, § 602(b)(1)(B).
Frm 00019
Fmt 4701
Sfmt 4702
563
2. Potential date when mobile device(s)
with CMAS support are available for
consumer purchase.
3. Whether the deployment will be ‘‘in
whole or in part’’.
It is important to understand the various
scenarios that may be deployed in CMSP
networks to support CMAS for those CMSP
that do elect to transmit the CMAS alerts in
whole or part. In addition, these scenarios
need to be understood for the development
of appropriate information a CMSP must
provide to the subscriber to educate them on
the availability of CMAS alerts. This
information also needed to educate the
sources of the CMAS alerts so there is not an
unrealistic expectation as to the percentage of
population to which the alert message may
be broadcast.
Note: The following diagrams show variety
of mobile devices (i.e. cellular mobile phones
and pagers) as illustrative examples; it is not
the intention to suggest all mobile device
technologies are supported by a single
operator or via a single CMSP network.
3.1 Scenarios for Single Technology
Deployed
3.1.1 Scenario—CMAS in Entire Single
Technology Operator Network on All Devices
This scenario illustrates where the CMSP
deploys a single delivery technology within
the CMSP network to support CMAS alerts,
and all mobile devices on that network
support the delivery technology and thus the
reception of the CMAS alerts.
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
3.1.2 Scenario—CMAS in Entire Single
Technology Operator Network on a Subset of
Devices
This scenario illustrates where the CMSP
deploys a single delivery technology within
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
the CMSP network to support CMAS alerts,
and only a subset of mobile devices on that
CMSP network support the delivery
technology and thus the reception of the
CMAS alerts.
PO 00000
Frm 00020
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.001
564
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
subset of the CMSP network to support
CMAS alerts, and all mobile devices on that
CMSP network support the delivery
technology and thus the reception of the
CMAS alerts while in the portion of the
PO 00000
Frm 00021
Fmt 4701
Sfmt 4702
CMSP network where the delivery
technology is deployed.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.002
sroberts on PROD1PC70 with PROPOSALS
3.1.3 Scenario—CMAS in Subset of Single
Technology Operator’s Network on All
Devices
This scenario illustrates where the CMSP
deploys a single delivery technology in a
565
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
3.1.4 Scenario—CMAS in Subset of Single
Technology Operator’s Network on Subset of
Devices
This scenario illustrates where the CMSP
deploys a single delivery technology in a
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
subset of the CMSP network to support
CMAS, and only a subset of mobile devices
on the CMSP network support the delivery
technology and thus the reception of the
CMAS alerts while in the portion of the
PO 00000
Frm 00022
Fmt 4701
Sfmt 4702
CMSP network where the delivery
technology is deployed.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.003
566
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
within the CMSP network to support CMAS
alerts, and all mobile devices on that CMSP
network support all delivery technologies
and thus the reception of the CMAS alerts.
PO 00000
Frm 00023
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.004
sroberts on PROD1PC70 with PROPOSALS
3.2 Scenarios for Multiple Technologies
Deployed
3.2.1 Scenario—CMAS in Entire Multiple
Technology Operator Network on All Devices
This scenario illustrates where the CMSP
deploys multiple delivery technologies
567
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
3.2.2 Scenario—CMAS in Entire Multiple
Technology Operator Network on Subset of
Devices
This scenario illustrates where the CMSP
deploys multiple delivery technologies
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
within the CMSP network to support CMAS
alerts, and only a subset of mobile devices on
the CMSP network supports one or both
delivery technologies and thus the reception
PO 00000
Frm 00024
Fmt 4701
Sfmt 4702
of the CMAS alerts. Some mobile devices
may not support either delivery technology.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.005
568
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
subset of the CMSP network to support
CMAS alerts, and only a subset of mobile
devices on the CMSP network support one or
both delivery technologies and thus the
reception of the CMAS alerts. Some mobile
PO 00000
Frm 00025
Fmt 4701
Sfmt 4702
devices may not support either delivery
technology. This is a realistic picture of the
deployment of CMAS, especially in a
nationwide scenario.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.006
sroberts on PROD1PC70 with PROPOSALS
3.2.3 Scenario—CMAS in Subset of
Multiple Technology Operator Network on
Subset of Devices
This scenario illustrates where the CMSP
deploys multiple delivery technologies on a
569
570
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
EP03JA08.008
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
PO 00000
Frm 00026
Fmt 4701
Sfmt 4725
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.007
sroberts on PROD1PC70 with PROPOSALS
3.3 Scenario for Operator Does Not Elect to
Transmit CMAS Alerts
This option illustrates where the CMSP
does not elect to transmit CMAS alerts.
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
3.4 Subscriber Notification
Recommendations
4
The CMSAAC, in collaboration with the
Cellular Telephone and Internet Association
(CTIA) and its membership developed the
proposed text to be used by commercial
mobile service providers to notify their
subscribers (1) when they intend to transmit
emergency alerts ‘‘in part’’ or (2) when they
do not intend to transmit emergency alerts.
The WARN Act appears not to require
specific text be developed for service
providers who elect to transmit emergency
alerts throughout its entire coverage area.
Therefore no text was developed for that
case.
3.4.1
Notification Procedures
The CMSAAC recommends that carriers
retain the discretion to determine how to
provide specific information regarding (1)
whether or not they offer wireless emergency
alerts, and (2) which devices are or are not
capable of receiving wireless emergency
alerts, as well as how to tailor additional
notice, if necessary, for devices offered at
other points of sale, i.e., retail outlets, mobile
virtual network operators (MVNOs) and third
party vendors.
sroberts on PROD1PC70 with PROPOSALS
3.4.2
Notification Text Recommendations
The CMSAAC submits the following
recommended notice text, consistent with the
requirements of the WARN Act.
I. NOTICE BY CARRIER WHO INTENDS TO
TRANSMIT EMERGENCY ALERTS ‘‘IN
PART.’’
NOTICE REGARDING TRANSMISSION OF
WIRELESS EMERGENCY ALERTS
(Commercial Mobile Alert Service)
[[WIRELESS PROVIDER]] has chosen to
offer wireless emergency alerts within
portions of its service area, as defined by the
terms and conditions of its service
agreement, on wireless emergency alert
capable devices. There is no additional
charge for these wireless emergency alerts.
Wireless emergency alerts may not be
available on all devices or in the entire
service area, or if a subscriber is outside of
the [WIRELESS PROVIDER’s] service area.
For details on the availability of this service
and wireless emergency alert capable
devices, please ask a sales representative, or
go to [[INSERT WEB SITE URL]].
Notice required by FCC Rule XXXX
(Commercial Mobile Alert Service).
II. NOTICE BY CARRIER WHO, ‘‘IN
WHOLE,’’ DOES NOT INTEND TO
TRANSMIT EMERGENCY ALERTS
NOTICE TO NEW AND EXISTING
SUBSCRIBERS REGARDING
TRANSMISSION OF WIRELESS
EMERGENCY ALERTS (Commercial
Mobile Alert Service)
[[WIRELESS PROVIDER]] presently does
not transmit wireless emergency alerts.
Notice required by FCC Rule XXXX
(Commercial Mobile Alert Service).
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAS Alert Scenarios
This section provides descriptions
recommended by the CMSAAC for many
common scenarios which are related to the
support of CMAS Alert messages. These
scenarios are a representative sample and do
not include all possible sequences and/or
events. Specifically this section will include
descriptions of the following scenarios:
• Nominal CMAS alert scenarios for text
based CMAS alert, as well as future
capabilities of streaming audio, streaming
video, and downloaded multimedia CMAS
alerts.
• CMAS alert cancellation scenario.
• CMAS alert update scenarios for text
based CMAS alert, as well as future
capabilities of streaming audio, streaming
video, and downloaded multimedia CMAS
alerts.
• CMAS alert expiration scenario.
• Duplicate CMAS alert scenarios for both
duplicate CMAS alerts on the same broadcast
technology and duplicate CMAS alerts from
different broadcast technologies.
• Multiple different active CMAS alert
scenarios.
• Multiple different CMAS alerts.
4.1 Nominal CMAS Alert Scenarios
4.1.1 Scenario for Nominal Text CMAS
Alert
An event has occurred and the appropriate
government entities have decided to issue a
text based CMA to warn the CMSP
subscribers within the indicated alerting
area.
This scenario applies to both the CMSP
subscribers and to subscribers who are
roaming as visiting subscribers into the
service area of the CMSP network which will
be broadcasting the CMA.
4.1.1.1 Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
3. Mobile device is in state that allows for
the detection and reception of the CMA (e.g.,
not busy, not on a voice call).
4. No previous Commercial Mobile Alert
Message (CMAM) is being broadcast by the
CMSP.
5. There is no active CMAM on mobile
device.
6. CMSP subscriber is within the alerting
area for the CMA.
4.1.1.2 Normal Flow
The normal flow for the text based CMA
is described in the following steps and in the
associated flow diagram which follows:
1. The appropriate government entity
creates the alert message in CAP format
which is sent to the government alerting
network over Reference Point A.
2. The government alerting network
validates and authenticates the received alert
request.
a. If the alert fails validation or
authentication, an error response is returned
PO 00000
Frm 00027
Fmt 4701
Sfmt 4702
571
to the originating government entity and the
alert is not sent to the CMSP. End of scenario.
3. The government alerting network
converts the received alert message into the
text profile based CMAS format supported by
the CMSP.
a. If the alert fails conversion, the alert is
not sent to the CMSP. End of scenario.
4. The text profile based CMAM is sent to
the CMSP over Reference Point C.
5. The CMSP validates the received
CMAM.
a. If the CMAM fails validation, an error
response is returned to the government
alerting network and the CMAM is not
broadcast by the CMSP. End of scenario.
6. The CMSP sends an acknowledgement
to the government alerting network that a
valid CMAM has been received.
7. The CMSP performs geo-targeting to
translate the indicated alert area into the
associated set of cell sites / paging
transceivers for the broadcast of the CMA.
a. If the CMSP does not support CMAS in
the indicated alert area, the CMAM is not
broadcast by the CMSP. End of scenario.
b. If the CMSP does not have any cell site
/ paging transceiver coverage within the
indicated alert area, the CMAM is not
broadcast by the CMSP. End of scenario.
c. If the entire nation is indicated as the
alert area then all cell sites / paging
transceivers of the CMSP which support the
CMAS service are used for the broadcast of
the CMAM.
8. The CMSP broadcasts the CMAM to the
set of cell sites / paging transceivers
identified by the geo-targeting processing in
the previous step.
a. The CMAM is broadcast via the CMSP
selected technology.
9. The mobile device monitors for the
broadcast of the CMAM via the CMSP
selected technology.
a. If the CMAM is not a Presidential alert
and if the end user opt-out selections for
CMAS alerts indicate that this type of CMAM
is not to be presented, the CMAM is
discarded or ignored. End of scenario.
10. The CMAM is received and presented
to the end user including the activation of the
CMAS audio attention signal and/or the
activation of the special emergency alert
vibration cadence (if mobile device has
vibration capabilities) for a short duration as
defined by CMSP policies and by the
capabilities of the mobile device, and display
of the CMAM message text on the visual
display of the mobile device.
a. Activation of the CMAS audio attention
signal and/or special vibration cadence
complies with the end user mobile device
configuration as defined in Section 7.2,
below.
11. The behavior of the mobile device
beyond this point is outside the scope of the
WARN Act and, therefore, is not subject to
recommendations by the CMSAAC. The
functionality of the mobile device is CMSP
and mobile device specific.
BILLING CODE 6712–01–P
E:\FR\FM\03JAP2.SGM
03JAP2
572
BILLING CODE 6712–01–C
4.1.2 Scenario for Nominal Streaming
Audio or Streaming Video CMAS Alert
Streaming audio or streaming video CMAS
alerts are a future capability.
4.1.3 Scenario for Nominal Downloaded
Multimedia CMAS Alert Downloaded
multimedia CMAS alerts are a future
capability.
sroberts on PROD1PC70 with PROPOSALS
4.2
CMAS Alert Cancellation Scenario
The event that caused the issuance of the
CMA has changed and the appropriate
government entities have decided that the
event is no longer an imminent threat to life
or property. Consequently the appropriate
government entities have decided to issue a
cancellation of the CMA.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
This scenario applies to both the CMSP
subscribers and to subscribers who are
roaming as visiting subscribers into the
service area of the CMSP network which will
be broadcasting the CMA.
If the received CMAM cancellation is not
valid and if, as a part of its implementation,
the CMSP has enabled message
retransmission, the CMSP may continue to
send the original alert until expiry or until
a valid CMAM cancellation is received.
4.2.1
Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
PO 00000
Frm 00028
Fmt 4701
Sfmt 4702
3. Mobile device is in state that allows for
the detection and reception of the CMA (e.g.,
not busy, not on a voice call).
4. A previous non-expired Commercial
Mobile Alert Message (CMAM) has been
broadcast by the CMSP and has been
received by the mobile device (i.e., there is
an active CMAM on the mobile device).
6. CMSP subscriber is within the alerting
area of the active CMA.
4.2.2 Normal Flow
The normal flow for the cancelled CMA is
described in the following steps and in the
associated flow diagram which follows:
1. The appropriate government entity
creates the alert cancellation message in CAP
format which is sent to the government
alerting network over Reference Point A.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.009
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
2. The government alerting network
validates and authenticates the received alert
cancellation request.
a. If the alert fails validation or
authentication, an error response is returned
to the originating government entity and the
alert cancellation is not sent to the CMSP.
End of scenario.
3. The government alerting network
converts the received alert message into the
text profile based CMAS format support by
the CMSP.
a. The Alert Gateway ensures that the
urgency, severity, certainty match the values
of those fields in the original message. As a
consequence, a cancelled CMAM passed to
the CMSP Gateway has the same urgency,
severity, certainty, and message category as
the original CMA alert in order to ensure the
opt-out filter on the handset is the same for
both messages. Therefore if the original
CMAM was ignored based on opt-out criteria,
then the CMAM cancellation should also be
ignored.
b. If the alert fails conversion, the alert
cancellation is not sent to the CMSP. End of
scenario.
4. The CMAM cancellation is sent to the
CMSP over Reference Point C.
5. The CMSP validates the received CMAM
cancellation.
a. If the CMAM cancellation fails
validation, an error response is returned to
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
the government alerting network and the
CMAM cancellation is not broadcast by the
CMSP. End of scenario.
6. The CMSP sends an acknowledgement
to the government alerting network that a
valid CMAM cancellation has been received.
7. The CMSP discontinues the broadcasts
the associated CMAM including the text
component and any associated audio, video,
or multimedia components.
8. The CMSP performs geo-targeting to
translate the indicated alert area into the
associated set of cell sites/paging transceivers
for the broadcast of the CMA.
a. If the CMSP does not support CMAS in
the indicated alert area, the CMAM is not
broadcast by the CMSP. End of scenario.
b. If the CMSP does not have any cell site/
paging transceiver coverage within the
indicated alert area, the CMAM is not
broadcast by the CMSP. End of scenario.
c. If the entire nation is indicated as the
alert area then all cell sites/paging
transceivers of the CMSP which support the
CMAS service are used for the broadcast of
the CMAM.
9. The CMSP broadcasts the CMAM
cancellation to the same set of cell sites /
paging transceivers identified by the geotargeting processing in the previous step.
10. The mobile device monitors for the
broadcast of the CMAM cancellation via the
PO 00000
Frm 00029
Fmt 4701
Sfmt 4702
573
CMSP selected technology and receives the
CMAM cancellation.
a. If the CMAM cancellation is not a
Presidential alert and if the end user opt-out
selections for CMAS alerts indicate that this
type of CMAM is not to be presented, the
CMAM cancellation is discarded or ignored.
End of scenario.
11. The CMAM cancellation is received
and the CMAM cancellation is presented to
the end user including the activation of the
CMAS audio attention signal and/or the
activation of the special emergency alert
vibration cadence (if mobile device has
vibration capabilities) for a short duration as
defined by CMSP policies and the
capabilities of the mobile device, and the
display of the CMAM cancellation message
text on the visual display of the mobile
device.
a. Activation of the CMAS audio attention
signal and/or special vibration cadence will
comply with the end user mobile device
configuration as defined in Section 7.2
below.
12. The behavior of the mobile device
beyond this point is outside the scope of the
WARN Act and, therefore, is not subject to
recommendations by the CMSAAC. The
functionality of the mobile device is CMSP
and mobile device specific.
E:\FR\FM\03JAP2.SGM
03JAP2
574
CMAS Alert Update Scenarios
4.3.1 Scenario for Update of Text CMAS
Alert
The appropriate government entities have
decided to issue an update to a previously
issued text based CMA to warn the CMSP
subscribers within the indicated alerting area
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
about changes associated with the event that
caused the issuance of the previous CMA.
This scenario applies to both the CMSP
subscribers and to subscribers who are
roaming as visiting subscribers into the
service area of the CMSP network which will
be broadcasting the CMA.
If the received CMAM cancellation is not
valid and if, as a part of its implementation,
PO 00000
Frm 00030
Fmt 4701
Sfmt 4702
the CMSP has enabled message
retransmission, the CMSP may continue to
send the original alert until expiration or
until a valid CMAM cancellation is received.
4.3.1.1
Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.010
sroberts on PROD1PC70 with PROPOSALS
4.3
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
3. Mobile device is in state that allows for
the detection and reception of the CMA (e.g.,
not busy, not on a voice call).
4. The CMSP may be broadcasting a
previous CMA which is associated with the
updated CMA.
5. A CMAM may be active on mobile
device.
6. CMSP subscriber is within the alerting
area of the updated CMA.
4.3.1.2 Normal Flow
The normal flow for the update of text
based CMAM is described in the following
steps and in the associated flow diagram
which follows:
1. The appropriate government entity
creates the updated alert message in CAP
format which is sent to the government
alerting network over Reference Point A.
2. The government alerting network
validates and authenticates the received
updated alert request.
a. If the alert fails validation or
authentication, or conversion, an error
response is returned to the originating
government entity and the alert is not sent to
the CMSP. End of scenario.
3. The government alerting network
converts the received alert message into the
text profile based CMAS format supported by
the CMSP.
a. The Alert Gateway ensures that the
urgency, severity, certainty match the values
of those fields in the original message. As a
consequence, an updated CMAM passed to
the CMSP Gateway has the same urgency,
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
severity, certainty, and message category as
the original CMA alert in order to ensure the
opt-out filter on the handset is the same for
both messages. Therefore if the original
CMAM was ignored based on opt-out criteria,
then the updated CMAM should also be
ignored.
b. If the alert fails conversion, the alert is
not sent to the CMSP. End of scenario.
4. The updated text based CMAM is sent
to the CMSP over Reference Point C.
5. The CMSP validates the received
updated CMAM.
a. If the updated CMAM fails validation, an
error response is returned to the government
alerting network and the updated CMAM is
not broadcast by the CMSP. End of scenario.
6. The CMSP sends an acknowledgement
to the government alerting network that a
valid updated CMAM has been received.
7. The CMSP discontinues any broadcasts
of the previously issued CMAM.
8. The CMSP performs geo-targeting to
translate the indicated alert area into the
associated set of cell sites/paging transceivers
for the broadcast of the updated CMAM.
a. If the CMSP does not support CMAS in
the indicated alert area, the updated CMAM
is not broadcast by the CMSP. End of
scenario.
b. If the CMSP does not have any cell site/
paging transceiver coverage within the
indicated alert area, the updated CMAM is
not broadcast by the CMSP. End of scenario.
c. If the entire nation is indicated as the
alert area then all cell sites/paging
transceivers of the CMSP which support the
PO 00000
Frm 00031
Fmt 4701
Sfmt 4702
575
CMAS service are used for the broadcast of
the updated CMAM.
9. The CMSP broadcasts the updated
CMAM to the set of cell sites/paging
transceivers identified by the geo-targeting
processing in the previous step.
a. The updated CMAM is broadcast via the
CMSP selected technology.
10. The mobile device monitors for the
broadcast of the updated CMAM via the
CMSP selected technology.
a. If the updated CMAM is not a
Presidential alert and if the end user opt-out
selections for CMAS alerts indicate that this
type of CMAS alert is not to be presented, the
updated CMAM is discarded or ignored. End
of scenario.
11. The updated CMAM is received and
presented to the end user including the
activation of the CMAS audio attention signal
and/or the activation of the special
emergency alert vibration cadence (if mobile
device has vibration capabilities) for a short
duration as defined by CMSP policies and
the capabilities of the mobile device, and the
display of the updated CMAM message text
on the visual display of the mobile device.
a. Activation of the CMAS audio attention
signal and/or special vibration cadence
complies with the end user mobile device
configuration as defined in Section 7.2
below.
12. The behavior of the mobile device
beyond this point is outside the scope of the
WARN Act and, therefore, is not subject to
recommendations by the CMSAAC. The
functionality of the mobile device is CMSP
and mobile device specific.
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
4.3.2 Scenario for Update of Streaming
Audio or Streaming Video CMAS Alert
Downloaded multimedia CMAS alerts are
a future capability.
functionality when the expiration time has
been detected.
Streaming audio or streaming video CMAS
alerts are a future capability.
4.4
4.4.1
4.3.3
Scenario for Update of
Downloaded Multimedia CMAS Alert
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAS Alert Expiration Scenario
The previously issued Commercial Mobile
Alert Message (CMAM) alert has reached its
expiration time without having been updated
or cancelled. This scenario describes the
PO 00000
Frm 00032
Fmt 4701
Sfmt 4702
Pre-Conditions
1. The associated non-expired noncancelled CMAM has been or is currently
being broadcast by the CMSP.
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.011
sroberts on PROD1PC70 with PROPOSALS
576
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Normal Flow
The normal flow for the CMAS alert
expiration is described in the following steps
and in the associated flow diagram which
follows:
sroberts on PROD1PC70 with PROPOSALS
4.5 Duplicate CMAS Alerts Scenarios
4.5.1 Scenario for Duplicate CMAS Alerts
on Same Broadcast Technology
A CMAM is being retransmitted by the
CMSP network. The mobile device detects
and ignores the duplicate CMAM.
This scenario applies to both the CMSP
subscribers and to subscribers who are
roaming as visiting subscribers into the
service area of the CMSP network which will
be broadcasting the CMA.
4.5.1.1 Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
1. The expiration time of a previously
issued CMAM has been determined by the
CMSP.
2. Any active broadcasts of text component
of the previously issued CMAM are
discontinued by the CMSP.
3. All active broadcasts of any associated
audio, video, or multimedia components of
the previously issue CMAM are discontinued
by the CMSP.
3. Mobile device is in state that allows for
the detection and reception of CMAM (e.g.,
not busy, not on a voice call).
4. A previous copy of the CMAM has been
broadcast by the CMSP.
5. The previous copy of the CMAM is
contained on mobile device.
6. CMSP subscriber is still within the
alerting area for the CMA.
a. The CMAM being retransmitted contains
the same message identifier as the previously
broadcast version.
b. The retransmission could be performed
by the CMSP selected delivery technology
depending on the capabilities of the delivery
technology.
2. The mobile device monitors for the
broadcast of the CMAM via the CMSP
selected technology.
3. The mobile device detects the received
CMAM as a duplicate CMAM based upon
message identifier and other message
attributes. The duplicate CMAM is ignored
and discarded by the mobile station.
4.5.1.2
Normal Flow
The flow for duplicate CMAM on the same
broadcast technology is described in the
following steps and in the associated flow
diagram which follows:
1. The CMSP network retransmits a
previously broadcast CMAM.
PO 00000
Frm 00033
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.012
4.4.2
577
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
4.5.2 Scenario for Duplicate CMAS Alerts
on Different Broadcast Technologies
An event has occurred and the appropriate
government entities have decided to issue a
text based CMA to warn the CMSP
subscribers within the indicated alerting
area. The CMSP network supports more than
one broadcast technology in the indicated
alerting area and the CMSP elects to
broadcast the CMA on more than one
technology in the indicated alerting area.
Support of multiple broadcast technologies
by the CMSP network may be result of the
deployment and implementation of newer
broadcast technologies. This scenario applies
to both the CMSP subscribers and to
subscribers who are roaming as visiting
subscribers into the service area of the CMSP
network which will be broadcasting the
CMA.
4.5.2.1 Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
3. Mobile device is in state that allows for
the detection and reception of the CMA (e.g.,
not busy, not on a voice call).
4. No previous CMAM is being broadcast
by the CMSP.
5. There is no active CMAM on mobile
device.
6. CMSP subscriber is still within the
alerting area for the CMA.
7. The mobile device is capable of
receiving the CMAM from more than one
broadcast technology.
4.5.2.2 Normal Flow
The flow for duplicate text profile based
CMAS alerts on the different broadcast
technologies is described in the following
steps and in the associated flow diagram
which follows:
1. The appropriate government entity
creates the alert message in CAP format
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
which is sent to the government alerting
network over Reference Point A.
2. The government alerting network
validates and authenticates the received alert
request.
a. If the alert fails validation or
authentication, an error response is returned
to the originating government entity and the
alert is not sent to the CMSP. End of scenario.
3. The government alerting network
converts the received alert message into the
text profile based CMAS format supported by
the CMSP.
a. If the alert fails conversion, the alert is
not sent to the CMSP. End of scenario.
4. The text profile based CMAM is sent to
the CMSP over Reference Point C.
5. The CMSP validates the received
CMAM.
a. If the CMAM fails validation, an error
response is returned to the government
alerting network and the CMAM is not
broadcast by the CMSP. End of scenario.
6. The CMSP sends an acknowledgement
to the government alerting network that a
valid CMAM has been received.
7. The CMSP performs geo-targeting to
translate the indicated alert area into the
associated set of cell sites/paging transceivers
for the first broadcast technology used for the
broadcast of the CMAM.
a. If the CMSP does not support CMAS in
the indicated alert area, the CMAM is not
broadcast by the CMSP. End of scenario.
b. If the CMSP does not have any cell site/
paging transceiver coverage for the first
broadcast technology within the indicated
alert area, the CMAM is not broadcast by the
CMSP using the first broadcast technology.
The CMAM will be processed as described in
Section 4.1.1 above. End of scenario.
c. If the entire nation is indicated as the
alert area then all cell sites/paging
transceivers of the first broadcast technology
of the CMSP which support the CMAS
service are used for the broadcast of the
CMAM.
PO 00000
Frm 00034
Fmt 4701
Sfmt 4702
8. The CMSP broadcasts the CMAM using
the first broadcast technology to the set of
cell sites/paging transceivers identified by
the geo-targeting processing in the previous
step.
a. The CMAM is broadcast via the first
CMSP selected technology.
9. The CMSP performs geo-targeting to
translate the indicated alert area into the
associated set of cell sites/paging transceivers
for the second broadcast technology used for
the broadcast of the CMAM.
a. If the CMSP does not have any cell site/
paging transceiver coverage for the second
broadcast technology within the indicated
alert area, the CMAM is not broadcast by the
CMSP using the second broadcast
technology. The CMAM is processed as
described in Section 4.1.1 above. End of
scenario.
c. If the entire nation is indicated as the
alert area then all cell sites/paging
transceivers of the second broadcast
technology of the CMSP which support the
CMAS service are used for the broadcast of
the CMAM.
10. The CMSP broadcasts the CMAM using
the second broadcast technology to the set of
cell sites/paging transceivers identified by
the geo-targeting processing in the previous
step.
a. The CMAM is broadcast via the second
CMSP selected technology.
11. The CMAM is received from both the
first and second broadcast technologies.
12. Based upon mobile device capabilities
and configurations, only one of the received
CMAM will be presented to the end user. The
mobile device should only perform one
activation of the CMAS audio attention signal
and/or the activation of the special
emergency alert vibration cadence (if mobile
device has vibration capabilities).
a. If the CMAM is not a Presidential alert
and if the end user opt-out selections for
CMAS alerts indicate that this type of CMAS
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.013
sroberts on PROD1PC70 with PROPOSALS
578
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
WARN Act and, therefore, is not subject to
recommendations by the CMSAAC. The
functionality of the mobile device is CMSP
and mobile device specific.
BILLING CODE 6712–01–P
BILLING CODE 6712–01–C
VerDate Aug<31>2005
20:47 Jan 02, 2008
Jkt 214001
PO 00000
Frm 00035
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.014
sroberts on PROD1PC70 with PROPOSALS
alert is not to be presented, the CMAM is
discarded or ignored. End of scenario.
13. The behavior of the mobile device
beyond this point is outside the scope of the
579
580
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
4.6 Multiple Different Active CMAS Alerts
Scenario
An event has occurred and the appropriate
government entities have decided to issue a
text based CMA to warn the CMSP
subscribers within the indicated alerting
area. During the broadcast period of the 1st
alert message, a second event has occurred
for the same alerting area and the appropriate
government entities have decided to issue a
second text based CMA to warn the CMSP
subscribers within the indicated alerting
area.
The CMSP processes CMAM received from
the Alert Gateway on a first come first served
basis. There is no prioritization of processing
or delivery of CMAM within the CMSP
network. This scenario applies to both the
CMSP subscribers and to subscribers who are
roaming as visiting subscribers into the
service area of the CMSP network which will
be broadcasting the CMA.
4.6.1
Pre-Conditions
1. Mobile device is authorized and
authenticated for service on CMSP network.
2. Mobile device is receiving adequate
radio signal strength from the CMSP.
3. Mobile device is in state that allows for
the detection and reception of CMA (e.g., not
busy, not on a voice call).
4. No previous CMAM is being broadcast
by the CMSP.
5. There is no CMAM on mobile device.
6. CMSP subscriber is within the alerting
area for the CMA.
7. Both CMA are to be issued for the same
alerting area.
4.6.2
Normal Flow
sroberts on PROD1PC70 with PROPOSALS
The flow for multiple different CMAS
alerts within the same alerting area is
described in the following steps and in the
associated flow diagram which follows:
1. The appropriate government entity
creates the 1st alert message in CAP format
which is sent to the government alerting
network over Reference Point A.
2. The government alerting network
validates and authenticates the 1st received
alert request.
a. If the 1st alert fails validation or
authentication, an error response is returned
to the originating government entity and the
alert is not sent to the CMSP. End of scenario.
3. The government alerting network
converts the 1st received alert message into
the text profile based CMAS format
supported by the CMSP.
a. If the alert fails conversion, the alert is
not sent to the CMSP. End of scenario.
4. The 1st text profile based CMAM is sent
to the CMSP over Reference Point C.
5. The CMSP validates the 1st received
CMAM.
VerDate Aug<31>2005
20:47 Jan 02, 2008
Jkt 214001
a. If the 1st CMAM fails validation, an error
response is returned to the government
alerting network and the CMAM is not
broadcast by the CMSP. End of scenario.
6. The CMSP sends an acknowledgement
to the government alerting network that the
1st received CMAM is valid.
7. The CMSP performs geo-targeting for the
1st CMAS alert to translate the indicated alert
area into the associated set of cell sites/
paging transceivers for the broadcast of the
1st CMAM.
a. If the CMSP does not support CMAS in
the indicated alert area, the 1st CMAM is not
broadcast by the CMSP. End of scenario.
b. If the CMSP does not have any cell site/
paging transceiver coverage within the
indicated alert area, the 1st CMAM is not
broadcast by the CMSP. End of scenario.
c. If the entire nation is indicated as the
alert area then all cell sites/paging
transceivers of the CMSP which support the
CMAS service are used for the broadcast of
the 1st CMA.
8. The CMSP broadcasts the 1st CMAM to
the set of cell sites/paging transceivers
identified by the geo-targeting processing in
the previous step.
a. The 1st CMAM is broadcast via the
CMSP selected technology.
9. The 1st CMAM is received and
presented to the end user including the
activation of the CMAS audio attention signal
and/or the activation of the special
emergency alert vibration cadence (if mobile
device has vibration capabilities) for a short
duration as defined by CMSP policies and by
the capabilities of the mobile device, and
display of the 1st CMAM message text on the
visual display of the mobile device.
a. If the 1st CMAM is not a Presidential
alert and if the end user opt-out selections for
CMAS alerts indicate that this type of CMAS
alert is not to be presented, the CMAM is
discarded or ignored.
b. Activation of the CMAS audio attention
signal and/or special vibration cadence
complies with the end user mobile device
configuration as defined in Section 7.2
below.
10. An appropriate government entity
creates a 2nd alert message in CAP format for
the same alerting area as the 1st alert
message. The 2nd alert message is sent to the
government alerting network over Reference
Point A.
11. The government alerting network
validates and authenticates the 2nd received
alert request.
a. If the 2nd alert fails validation or
authentication, an error response is returned
to the originating government entity and the
alert is not sent to the CMSP. End of scenario.
12. The government alerting network
converts the 2nd received alert message into
PO 00000
Frm 00036
Fmt 4701
Sfmt 4702
the text profile based CMAS format
supported by the CMSP.
a. If the alert fails conversion, the alert is
not sent to the CMSP. End of scenario.
13. The 2nd text profile based CMAM is
sent to the CMSP over Reference Point C.
14. The CMSP validates the 2nd received
CMAM.
a. If the 2nd CMAM fails validation, an
error response is returned to the government
alerting network and the CMAM is not
broadcast by the CMSP. End of scenario.
15. The CMSP sends an acknowledgement
to the government alerting network that the
2nd received CMAM is valid.
16. The CMSP performs geo-targeting for
the 2nd CMAM to translate the indicated
alert area into the associated set of cell sites/
paging transceivers for the broadcast of the
2nd CMAM.
a. For this scenario, since the indicated
alert area of the 1st and 2nd CMAM are the
same, the results of the geo-targeting for both
the 1st and 2nd CMAM should return the
same set of cell sites/paging transceivers.
17. The CMSP broadcasts the 2nd CMAM
to the set of cell sites/paging transceivers
identified by the geo-targeting processing
step.
a. The 2nd CMAM is broadcast via the
CMSP selected technology.
b. The retransmission of the 1st CMAM
and the initial transmission of the 2nd
CMAM may be simultaneously broadcast, or
may be transmitted sequentially, depending
on the delivery technology.
18. The 2nd CMAM is received and
presented to the end user including the
activation of the CMAS audio attention signal
and/or the activation of the special
emergency alert vibration cadence (if mobile
device has vibration capabilities) for a short
duration as defined by CMSP policies and by
the capabilities of the mobile device, and
display of the 2nd CMAM message text on
the visual display of the mobile device.
a. If the 2nd CMAM is not a Presidential
alert and if the end user opt-out selections for
CMAS alerts indicate that this type of CMAS
alert is not to be presented, the 2nd CMAM
is discarded or ignored.
b. Activation of the CMAS audio attention
signal and/or special vibration cadence
complies with the end user mobile device
configuration as defined in Section 7.2
below.
c. The mobile device ignores the
retransmission of the duplicate 1st CMAM.
d. The mobile device processing and
presentation of multiple received CMAS
alerts is outside the scope of the WARN Act
and, therefore, is not subject to
recommendations by the CMSAAC. The
functionality of the mobile device is CMSP
and mobile device specific.
E:\FR\FM\03JAP2.SGM
03JAP2
5 General Requirements & Conclusions
The following section contains the
CMSAAC’s general recommendations and
conclusions for the CMAS. Many of the
conclusions and recommendations apply to
initial deployments of the CMAS, for a text-
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
based service profile. Future technologies,
such as streaming audio, streaming video,
and multimedia, are mentioned throughout
this document; however, technology
advances to support these future capabilities
are just beginning to be developed and
PO 00000
Frm 00037
Fmt 4701
Sfmt 4702
581
introduced. As CMSPs gain experience with
these technologies, the applicability of those
technologies to the CMAS will be better
understood.
The CMSAAC recommends that this
document be treated as a living document,
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.015
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
582
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
with periodic updates to account for
experiences with initial CMAS deployments
and experiences with new technologies and
their applicability to CMAS. An industry
group consisting of government and industry
stakeholders should be created after the
CMSAAC’s activity is complete to review and
update this document on a periodic basis.
This review should occur no less frequently
than biennially. It is expected that during
research, development, and deployment, this
industry group may need to convene more
frequently than biennially to address
research conclusions and any development
or deployment issues.
5.1 Scope & Definition of CMAS Alerts
The CMSAAC recommends that there are
three classes of Commercial Mobile Alerts:
1. Presidential-level.
2. Imminent threat to life and property
(defined as alerts where the CAP severity
equals Extreme or Severe, CAP urgency is
Immediate or Expected, and CAP certainty is
Observed or Likely).
3. Child Abduction Emergency or ‘‘AMBER
Alert’’.
Because of the technical limitations in
delivering emergency alerts on CMSP
systems, the CMSAAC recommends that only
the 3 classes defined above will be
transmitted as CMA messages.
The CMSAAC recommends that the CMSPs
who elect to support CMAs are considered
for this purpose only to be agents of the
federal, state, local, or tribal agencies that
originate the alerts and are providing CMAs
on their behalf.
A CMSP that elects to transmit alerts under
Section 602(b)(2) of the WARN Act may not
impose a separate or additional charge for
such transmission or capability when the
emergency alerts are transmitted in a manner
consistent with the technical standards,
protocols, procedures, and other technical
requirements implemented by the
Commission. For transmission or service
beyond standards, protocols, procedures, and
other technical requirements implemented by
the Commission, a Commercial Mobile
Service licensee is not bound by Section
602(b)(2)(C) of the WARN Act.
The Commercial Mobile Service licensee
may utilize the technical standards,
protocols, procedures, and other technical
requirements implemented by the
Commission to support the WARN Act for
other services or purposes and are not bound
by Section 602(b)(2)(C) of the WARN Act.
The government portion, from Reference
Point A to Reference Point C, of the CMAS
will not be made available for commercial
use.
CMAS will be provided according to the
technical standards, protocols, procedures,
and other technical requirements
implemented by the Commission to support
the WARN Act. A CMSP’s networks shall not
be bound to use any specific vendor,
technology, software, implementation, client,
device, or third party agent, in order to meet
the obligations under the WARN Act.
Technical standards, protocols,
procedures, and other technical requirements
implemented by the Commission shall be
standardized in industry fora which have a
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
well-defined reasonable and nondiscriminatory intellectual property rights
policy, allowing for multi-vendor
implementations.
It is anticipated that mobile devices that
support CMAS may incur additional
development and manufacturing costs and
these costs may be passed on to the
subscriber.
A CMSP or any device deployed by a
CMSP to support the transmission of CMAS
alerts according to the WARN Act shall not
be required to identify location or location
history of the mobile device.
The CMSAAC recommends that, prior to
the adoption of rules as specified in the
WARN Act Section 602 (b) (1), the
Commission will require all participants in
the CMSAAC and all participants in the
public comment process on this Commercial
Mobile Alert Service Architecture and
Requirements document to provide written
assurance to the Commission that, if and
insofar as one or more licenses may be
required under any of their respective
Intellectual Property Rights (IPR) that are
technically essential for purposes of
implementing or deploying CMAS, the rights
holders shall license such IPR on a fair,
reasonable and nondiscriminatory basis for
those limited purposes only.
5.2 General CMAS Requirements &
Conclusions
This section contains the CMSAAC’s
recommendations for general requirements
and assumptions for CMAS. More specific
requirements and assumptions may be
contained within the other sections of this
document.
1. Federal, state, tribal, and local level
CMAS alert messages will be supported using
the same CMAS solution.
2. Point-to-point or unicast delivery
technologies are not feasible or practical for
the support of CMAS, i.e., SMS point-topoint, MMS. Reasons for point-to-point
technologies not being feasible or practical
are:
a. Point-to-point technologies can
experience significant delivery delays.
b. Point-to-point technologies can result in
network and radio interface congestion to the
point of blocking voice calls.
c. Point-to-point technologies lack security
and can be easily spoofed.
d. Point-to-point technologies lack geotargeting capabilities because it is targeted to
phone numbers instead of a specific alert
area.
e. Point-to-point technologies lack
emergency alert specific alert tones and
thereby emergency alerts can not be
distinguished from normal SMS message
traffic.
f. Point-to-point technologies lack support
of roamers.
3. For a CMSP that elects to transmit
CMAS alerts, text is the minimum
requirement for CMAS alert messages. All
CMAS alert messages delivered to the CMSP
will contain at least a textual component.
4. No new CALEA lawful intercept access
points will be created for CMAS alert
broadcast delivery technologies.
5. There is no interaction between CMAS
alert message delivery and Number
PO 00000
Frm 00038
Fmt 4701
Sfmt 4702
Portability. There is no guarantee that the
end user will receive the CMAS alert message
during the time interval that the user’s
subscription is being ported between CMSPs.
As part of Number Portability, there is no
service portability between CMSPs.
6. It is not a requirement to support CMAS
on non-initialized mobile devices, including
mobile devices that are not authorized for
service.
7. CMAS is intended for commercial
mobile services (i.e, cellular phones and
pagers) supported by commercial mobile
service licensees. Some devices are not
designed to support CMAS (e.g., telematics,
data only devices such as laptop data cards)
and thus are outside the scope of the CMAS
architecture.
a. Broadcast technologies such as
MediaFLO, DVB–H, and FM/RBDS receivers
are not considered as part of the CMAS.
Service providers of these technologies do
not hold commercial mobile service licenses
as they do not provide interconnect service,
and are not licensed to transmit in the same
channels as commercial mobile services. It is
recognized that these technologies may
provide supplemental alert information for
the CMAS.
8. The CMAMs are delivered across
Reference Point C to the CMSP network at no
cost to the CMSP.
5.3 Recommendations for Alert Initiation &
Alert Initiators
5.3.1 CMAM Elements
A typical emergency alert message issued
by the National Weather Service on weather
radio might appear as follows:
‘‘The National Weather Service in Phoenix
has issued a severe thunderstorm warning for
northwest Maricopa County effective until 5
p.m. local time. Seek shelter now inside a
sturdy structure and stay indoors!’’
(Note the above message contains over 200
characters and spaces and is not in the
correct format for a CMAM).
The CMSAAC recommends that CMAMs
follow this same general format, within the
text character limitations of CMA as defined
in the text profile in Section 6.2 below. Given
the rapidly evolving nature of wireless
technology, the biennial review committee
shall review whether the character limit
profile, as described in Section 6.2, may be
increased.
The necessary elements of an effective
CMAM and the order in which they should
be presented in the CMAM are:
1. What’s happening (Event Type or Event
Category).
2. Area affected (in this area).
3. Recommended action (Response
description).
4. Expiration time with time zone
(Represented as a distinct time—e.g., until
09:30 a.m. EDT).
5. Sending agency (agency type, i.e., police,
fire, National Weather Service, etc.).
Note: The above format for a CMAM is
recommended for initial deployments of
CMAS and as experience is gained by alert
initiators and by CMSPs, we envision that the
format will evolve to provide the most
efficient and informative format for the
CMAMs.
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
5.3.2
Generating CMAM From CAP Fields
For initial CMAS system deployments and
until Alert Initiators are trained in the
generation of CMAM, in order to create
consistent and accurate CMAMs, the
CMSAAC recommends that the Alert
Gateway ‘‘construct’’ the CMAM using
selected required and optional fields in the
CAP message. The translated CMAM will
then be transmitted to the CMSP across the
Reference Point C.
Allowing the Alert Gateway to create the
CMAM using CAP fields creates consistent
and accurate messages and will enable
enhancements to be made over time in the
Alert Gateway and made available to all CMA
capable mobile devices in the field. For
instance, if a new alert event is identified, a
new event code or category can be added to
the CAP message, translated in the Alert
Gateway and a new text string can be sent to
the mobile device through the CMSP
Gateway.
However, generating CMAM using CAP
fields may not provide flexibility to Alert
Initiators to tailor the CMAM content to a
specific alert event. Even though CMAS is
not intended to provide comprehensive alert
information, a CMAM with a ‘‘what is
happening’’ text indicating ‘‘security
warning’’ may not be very meaningful to the
end user. The recent steam pipe explosion in
New York City and the Virginia Tech
shootings are examples where an
automatically generated CMAM would not
have provided meaningful information in the
CMAM text.
The CMSAAC recommends the use of the
sender identity used by the Alert Gateway in
the Trust Model to identify the sender. The
Alert Gateway will then assign an agreed
upon text phrase or abbreviation (e.g., VDOT,
NWS, etc.) to be transmitted to the CMSP
Gateway.
The CMSAAC makes the following
recommendations regarding the use of the
required category and optional eventCode
CAP fields. They are:
1. Encourage the National Weather Service
to continue its practice of using codes, such
as SAME codes, in the eventCode field to
identify weather alerts.
2. When the eventCode field is populated
with a value, that value will be used by the
Alert Gateway to determine what text phrase
will be transmitted to the CMSP gateway
(e.g., TOR will be translated to Tornado
Warning).
3. If the eventCode field is not populated
or is populated with a value unknown to the
Alert Gateway, the required category field
will be used by the Alert Gateway to
determine what text phrase to be transmitted
to the CMSP gateway.
4. Emergency message originators and the
National Weather Service are encouraged to
utilize codes for eventCodes. These codes
should be known by the Alert Gateway and
have appropriate text phrases associated with
them to be transmitted to the CMSP gateway.
The CMSAAC recommends that a process be
developed by which new event codes in
addition to the standard SAME and CAP
event codes can be developed and registered.
The CMSAAC recommends that the
affected area be generated from the optional
geocode field. If the optional geocode field is
missing, the polygon or circle elements will
be used to determine the associated geocodes
and the corresponding affected area
description. The CMSAAC further
recommends that a process be developed by
which new geocodes in addition to standard
FIPS codes can be registered and
implemented in the Alert Gateway for
deriving the affected area description.
The CMSAAC recommends that the
response description will be taken from the
optional responseType CAP Field. If the field
is not populated, the message should be
transmitted with the text string ‘‘Check local
media for info’’ applied. The CMSAAC
further recommends that a process be
developed by which new responseType
Codes in addition to the standard CAP
response type codes can be developed and
registered.
The CMSAAC recommends that the
expiration time will be determined from the
optional expires CAP field. If this field is not
populated, local guidelines will be applied
by the Alert Gateway as to when the message
is no longer in effect.
The following table defines the text string
associated with the CAP value fields used to
generate the CMAM:
TABLE 5–1.—CAP VALUE FIELD MAPPING TO TEXT
CAP field
Value
Text string
What is happening
category ............................
sroberts on PROD1PC70 with PROPOSALS
eventCode ........................
VerDate Aug<31>2005
Met ....................................................................................
Safety ................................................................................
Fire ....................................................................................
Geo ...................................................................................
Security .............................................................................
Rescue ..............................................................................
Health ................................................................................
Env ....................................................................................
Transport. ..........................................................................
TOR ...................................................................................
VOW ..................................................................................
SVR ...................................................................................
EQW ..................................................................................
TSW ..................................................................................
BZW ..................................................................................
DSW ..................................................................................
FFW ..................................................................................
HWW .................................................................................
HUW ..................................................................................
TRW ..................................................................................
WSW .................................................................................
CFW ..................................................................................
FLW ...................................................................................
FRW ..................................................................................
SMW .................................................................................
AVW ..................................................................................
CDW ..................................................................................
CEM ..................................................................................
HMW .................................................................................
LEW ..................................................................................
CAE ...................................................................................
NUW ..................................................................................
RHW ..................................................................................
20:42 Jan 02, 2008
Jkt 214001
PO 00000
Frm 00039
Fmt 4701
Sfmt 4702
583
Severe Weather Warning.
Public Safety Warning.
Fire Warning.
Geologic Warning.
Security Warning.
Rescue Alert.
Health Warning.
Environmental Warning.
Transport Alert.
Tornado Warning.
Volcano Warning.
Severe TStorm Warning.
Earthquake Warning.
Tsunami Warning.
Blizzard Warning.
Dust Storm Warning.
Flash Flood Warning.
High Wind Warning.
Hurricane Warning.
Tropical Storm Warning.
Winter Storm Warning.
Coastal Flood Warning.
Flood Warning.
Fire Warning.
Special Marine Warning.
Avalanche Warning.
Civil Danger Warning.
Civil Emergency.
HazMat Warning.
Police Warning.
AMBER Alert.
Nuclear Power Plant Warning.
Radiological Hazard Warning.
E:\FR\FM\03JAP2.SGM
03JAP2
584
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
TABLE 5–1.—CAP VALUE FIELD MAPPING TO TEXT—Continued
CAP field
Value
Text string
What area is affected
‘‘in this area’’
When the alert expires
expires ..............................
The expiration time of the information of the alert message. The date and time is represented in [dateTime]
format (e.g., ‘‘2002–05–24T16:49:00–07:00’’ for 24
May 2002 at 16:49 PDT).
Translated by the Alert Gateway to an event expires
time in a 12 hour/Time zone format (i.e., Until7:00AM
PDT).
What action should be taken
responseType ...................
Shelter or SPW .................................................................
Evacuate or EVI ................................................................
Prepare .............................................................................
Execute .............................................................................
Avoid Hazard 8 ..................................................................
Take Shelter Now.
Evacuate Now.
Prepare for Action.
Execute Action.
Avoid Hazard.
Who is sending the alert
sroberts on PROD1PC70 with PROPOSALS
sender ...............................
Identifies the originator of this alert. Guaranteed by assigner to be unique globally; e.g., may be based on an
Internet domain name—could also come from the
sender’s name in the Trust Model.
5.3.2.1 Generating CMAM From Free Form
Text
As indicated in the above section, the
generation of CMAM using CAP fields may
not provide flexibility to Alert Initiators to
tailor the CMAM content to a specific alert
event where only an event category is
available such as a ‘‘security warning’’. In
addition, Alert Initiators may want to provide
specific response information above what is
available in the CAP responseType field.
The CMSAAC recommends that a
capability be provided for Alert Initiators to
generate free form text consistent with the
text profile of Section 6.2, below. The
CMSAAC further recommends that the Alert
Gateway have a mechanism to determine
when the free form text should be used
instead of the automatically generated
CMAM described in Section 5.3.2 above. The
Alert Gateway mechanism is subject to the
implementation of the Alert Gateway and the
policy of the authorized government entity.
The CMSAAC recommends that the FCC
establish a forum that includes the CMSPs to
develop the Alert Gateway mechanism and
policy for free form text-based CMAMs that
will be subject to final approval of the
CMSPs. This policy would encompass
specific decision points at the Alert Gateway
such as: the message length does not exceed
the maximum character limit, the message
contains no phone numbers or URLs which
would encourage mass access of the wireless
network, the message contains all the
necessary elements of an effective message
referenced in section, etc. If any of the
decision points are not met, the
automatically generated message would be
8 This value is recommended for CMAS use only
pending inclusion into the CAP standard by the
responsible standards body.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Translated by the Alert Gateway to an acronym or short
abbreviation picked by the sender.
Note: URLs, phone numbers, and email addresses are
not sent to the mobile device.
issued to the CMSP instead of the free form
text.
The CMSAAC recommends that the Alert
Gateway issue automatically generated
CMAMs for alerts other than presidential and
AMBER Alert messages until free form
CMAMs meet the policies established for the
Alert Gateway.
If the use of free form text messages
becomes problematic or induces network
disruptions in practice, the Alert Gateway
mechanism and policy would need to be
modified to further restrict the issuance of
free form text messages or to utilize only
automatically generated CMAMs.
The free form text for the CMAM should
be included as a parameter of the CAP
message with the valueName indicating
‘‘CMAMtext’’.
The CMSAAC further recommends that
training be provided to Alert Initiators on
generation of meaningful CMAM which
provides sufficient information on the mobile
devices. It is recommended that the above
mentioned forum participate in the
development of the training program for free
form text targeted for CMAMs.
5.3.3 Presidential Message and AMBER
Alert
There are two additional special cases
where automatic text generation at the Alert
Gateway would not be practical. These are
the Presidential Alert message and AMBER
Alerts. The CMSAAC recommends that:
1. They may be identified either by a code
in the optional CAP eventCode field—EAN
for Presidential Alert and CAE for AMBER
Alert—or by the required CAP sender field.
Presidential level messages are not restricted
to nationwide only alert messages. The
Presidential level message may contain
polygon, circle, GNIS, or geocode
PO 00000
Frm 00040
Fmt 4701
Sfmt 4702
information to designate the targeted alert
area.
2. The free text message would be
presented to the Alert Gateway in a free text
CAP field. This free text message would be
transmitted to the CMSP gateway. For
Presidential alerts, the Alert Gateway may
use a generic statement such as ‘‘The
President has issued an emergency alert.
Check local media for more details’’.
3. It may be desirable for some AMBER
Alert messages to include specific
information such as a vehicle license plate.
The National Center for Missing and
Exploited Children (NCMEC) should be
authorized to formulate unique free-form
message text for CMAS.
4. These two special cases will use the
normal processes for sending messages to the
Alert Aggregator (i.e., use of CAP messages)
and will be treated as any other emergency
alert initiated message except as specified
above and in Section 2.2.2 above.
5.3.4 Recommended Message Initiator
Training
In order for emergency message initiators
to develop and transmit effective emergency
messages, within the character length limits
of the CMAM, the CMSAAC recommends
that alert initiator training on consistently
populating CAP fields and generating CMAM
be accomplished via the credentialing
process (See Section 8.1 below).
5.4 Recommendations for Geo-Targeting of
CMAS Alerts
The CMSAAC acknowledges that it is the
goal of the CMAS for CMSPs to be able to
deliver geo-targeted alerts to the areas
specified by the Alert Initiator. Systems used
by Alert Initiators may allow them to define
an alert area on a map. For example, the
defined alert area could include the projected
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
path of a tornado or an event that
encompasses a portion of an urban area. The
CMSAAC further recognizes that CMSPs
currently have limited capability to deliver
geo-targeted alerts.
Based upon current capabilities, the
CMSAAC recommends the following for geotargeting of CMAS alerts:
1. In order to expedite initial deployments
of CMAS an alert that is specified by a
geocode, circle or polygon (See Section 10.4)
will be transmitted to an area not larger than
the CMSP’s approximation of coverage for
the county 9 or counties with which that
geocode, circle, or polygon intersects. Some
wireless technology RF propagation areas, for
systems such as paging systems or multicounty cell sites, may greatly exceed a single
county. In these instances, CMSPs will
support geo-targeting subject to the
limitations imposed by their technology. Cell
sites’/paging transceivers’ physical location
within the alert area may be used to
determine the initial predefined alert areas.
The CMSP is not required to perform RF
coverage mapping of cell sites/paging
transceivers to initial alert areas.
a. A CMSP may elect to target smaller
areas. CMSP may elect to target CMAM for
distributions to predefined alert areas smaller
than a county and may use GNIS codes,
polygon, or circle information to identify a
predefined list of cell sites/paging
transceivers within the alert area. In the
interim period before the availability of
dynamic targeting, the CMSAAC
recommends that certain urban areas with
populations exceeding 1,000,000 inhabitants
or with other specialized alerting needs be
identified for priority consideration regarding
implementation of more precise geotargeting. The CMSAAC further recommends
that a process be established by the Alert
Gateway operator and the CMSPs to identify
no later than August 2008 those initial areas
that should be given such priority treatment
for more precise geo-targeting. The CMSAAC
recognizes the desire to move forward with
this process on a small number of areas with
particularly urgent alerting needs as soon as
possible. The CMSAAC recommends that
Section 604 funding be provided to FEMA for
this purpose.
2. The CMSAAC recognizes that the use of
predefined sets of cell sites frequently will
not optimally cover the alert area desired.
Therefore, the CMSAAC recommends that
the FCC encourage DHS/FEMA, in concert
with CMSPs, to immediately initiate the
research, development, testing, and
evaluation program referenced in Section 604
of the WARN Act. Section 604 requires DHS
to establish a program to develop innovative
technologies that will allow CMSPs to
efficiently transmit geo-targeted CMAMs to
the public. The CMSAAC further
recommends that CMSPs work with this DHS
program to evaluate the feasibility and
implementation issues associated with
proposed solutions to increase geographic
targeting specificity. Finally, the CMSAAC
recommends that the FCC assess the progress
of the CMSP geo-targeting as part of the
biennial review process.
9 County,
parish or equivalent jurisdictional area.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
3. The architecture to support CMAS shall
not require the CMSPs to open the
configuration, interfaces and topology of
their network including cell or paging
transceiver towers to any third parties, nor
provide subscriber information or data
outside their network. A CMSP shall not be
required to report cell site/paging transceiver
information, coverage information, or any RF
properties of their respective networks. The
CMSP shall be the sole agent responsible for
determining which network facilities,
elements, or locations are involved in
transmitting an alert to a mobile device.
4. Transmission of alerts shall be to twodimensional areas. There shall not be any
altitude or ceiling component.
5.5 Requirements and Recommendations
on Needs of Users, Including Individuals
With Disabilities and the Elderly
The WARN Act requirements for the
establishment of the Commercial Mobile
Service Alert Advisory Committee
membership specifically call for
representation from ‘‘national organizations
representing individuals with special needs,
including individuals with disabilities and
the elderly’’.10
During its work, the CMSAAC reviewed
input from members on accessibility
considerations. Most of the following
requirements benefit all subscribers in an
emergency.
It is recognized that not all wireless
devices have the features to support all
recommendations, but manufacturers are
strongly encouraged to implement those
recommendations that are technically
feasible, so that their mobile devices can
accommodate as many users as possible for
emergency alerting.
5.5.1 General Requirements
In order to notify mobile service
subscribers that an emergency alert message
has been received on the mobile device, the
CMSAAC recommends that the CMAS
support a common audio attention signal and
a common vibrating cadence to be used
solely for CMAMs. These alerting
mechanisms must be distinct from all other
audio alerting signals and vibrations
available in the mobile device and must not
be able to be selected or modified by the user
for any other purpose. The CMAS audio
attention signals and vibration cadence
signals as defined in Section 7.2 below are
applicable to all mobile devices which
support CMAS including any specialized
mobile devices for individuals with special
needs.
In addition, the CMSAAC recommends
that the user should not be required to
remember or use a unique command to turn
off the notification of the CMAM. A familiar
10 Beyond the WARN Act, consideration may be
given to legislation such as Title II of the Americans
With Disabilities Act which requires accessibility to
state and local government programs and
communications; Section 504 of the Rehabilitation
Act which requires accessibility of Federal
government programs; Section 255 of the
Communications Act which requires accessibility
in telecommunications products where readily
achievable; and Section 508 which applies to
Federal government purchase of wireless devices.
PO 00000
Frm 00041
Fmt 4701
Sfmt 4702
585
command, consistent with the other
commands used for call or message handling
on the mobile device, is recommended.
5.5.2 User Needs Requirements
5.5.2.1 Alert/Attention Signal
A unique vibration cadence (if supported
by the mobile device) should be provided as
well as a unique audio attention signal. If
both are available, the two modes do not
need to be activated simultaneously but will
follow the user’s settings in the handset. If
the handset supports dual activation the
signals will be simultaneous according to
user settings, but otherwise will be separate
signals. The vibration cadence for the alert
signal should be noticeably different from the
default cadence of the handset.
For devices that have polyphonic
capabilities, the CMSAAC recommends that
the audio attention signal should consist of
more than one tone, all of which are to be
in the low frequency range below 2 kHz, and
preferably below 1 kHz. For devices which
have only single frequency audio alert tone
capability, it is recommended that the audio
alert tone be in the low frequency range
below 2 kHz. The CMSAAC further
recommends, subject to mobile device
capabilities, that the signal have a temporal
pattern (on-off pattern) to make it easier to
detect, particularly in noisy conditions and
by people with hearing loss. See Section 7
below for additional information.
An audio attention signal starting with a
lower intensity and going to a higher
intensity during the tone sequence may
effectively get attention while endeavoring to
avoid unduly startling the message recipient.
Some mobile devices may support this
capability; however, such a capability is
controlled by the subscriber preferences for
audio attention signal settings; this capability
is not applicable to all mobile devices and
should be implemented at the discretion of
the mobile device vendors.
5.5.2.2 Message Content
The CMSAAC makes the following
recommendations regarding message content:
General Guideline: alert initiator use clear
and simple language whenever possible, with
minimal use of abbreviations. The most
important information should be presented
first.
Text messages: Follow General Guideline.
Audio messages: Follow General
Guideline. The alert initiator must insure
abbreviations are spoken as full words.
Video messages: Follow General Guideline.
Multimedia messages: The alert initiator
should provide ample text and audio to
explain images such as maps, so that message
recipients understand the content of the
graphics/images.
5.5.2.3 Output Mode/Display
The CMSAAC makes the following
recommendations regarding output mode/
display:
General Guideline: The mobile device
should provide an easy way to allow the user
to recall the message for review.
Outside the scope of CMSAAC are
alternate delivery mechanisms that would
enable a CMAS-registered person to sign up
with a third party for alternate format
E:\FR\FM\03JAP2.SGM
03JAP2
sroberts on PROD1PC70 with PROPOSALS
586
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
message delivery. This would provide the
means to access speech delivery for people
who do not have text-to-speech (TTS)
functionality in their phones, and would
enable delivery of American Sign Language
(ASL) if available and supported by the user’s
handset and service. The CMSAAC
recommends that the Alert Aggregator have
the capability to deliver alerts to third party
services in order for them to deliver
accessible alerts to users with special needs.
The need to support languages other than
English is recognized. See Section 5.7 MultiLanguage CMAS Alert Recommendations
below for further information.
Text Messages:
The mobile devices should use a font to
make the message easily readable. Per the
American Foundation for the Blind, the goal
in font selection is to use easily recognizable
characters, either standard Roman or Sans
Serif fonts. Another good choice is Arial.
Avoid decorative fonts.
The use of color should be avoided for the
purpose of conveying information, as some
people are color-blind, and some devices do
not display color.
If technically feasible, the mobile device
display should provide high contrast display
and provide adjustable font size.
One area of particular concern is that
people who are blind or visually impaired
will be most underserved by a solely textbased CMAM. The Committee recognizes that
these subscribers could be best served by
having the CMAM made available in speech
format. There are mobile devices and
software on the market with screen reading
and text-to-speech conversion capability. It is
agreed that such specialized mobile devices,
which are geared for people who are blind
and who have low vision, could be a
solution.11 The CMSAAC recommends that
participating CMSPs who elect to transmit
CMAS alert messages strongly consider
offering this capability.
In mobile devices/software that includes
capabilities to support text-to-speech access,
the CMAS text should be accessible to the
screen-reading functions in phones that are
capable of generating text-to-speech. The optout menus on displays also should be
available to these screen readers. The
CMSAAC recommends that the CMAS text is
accessible to these screen readers when
CMAS capability is incorporated in those
devices.
Future Audio Alert Message:
Follow the general guideline. Alert
initiators should insure that speech is
enunciated and presented at a slow pace.
Alert initiators should provide a text version
along with the audio version. Note this is not
the text-based alert; this is a multimedia alert
that contains both a text and audio
component consistent with the multimedia
profiles.
Future Video Alert Message:
Follow the general guideline. Alert
initiators should provide text versions of the
audio content of video alerts. CMSPs and
11 For more information, the American
Foundation for the Blind (AFB) is an authoritative
resource for accessible devices and related
technology developments: https://www.afb.org.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
mobile device vendors should consider
appropriate methods for delivery and
allowing users the ability to display this
associated text on mobile devices as
technology evolves and video and captioning
capabilities become available. Also, the alert
initiator should provide an audio description
of the video content as a separate multimedia
audio component consistent with the
multimedia profiles.
Future Multimedia Alert Message:
Follow the general guideline. The alert
initiator should provide all information in
text and graphical form as part of the
multimedia components to the alert message.
The alert initiator should provide an audio
description of the important information
supplied in the graphic, which is a separate
multimedia component consistent with the
multimedia profiles.
5.5.2.4 Behavior on Receipt of a Message
It is desirable to have the CMAM
prominently presented on the mobile device
without user interaction when the alert
message is received. To turn off the
notification of the CMAS message, a familiar
command consistent with the other
commands used for message handling on the
mobile device is recommended. It is best to
avoid requiring the subscribers to remember
and use a unique command or command
sequence. The need to scroll or manipulate
the device should be minimized.
5.5.2.5 CMAS-Related Print and Online
Materials
As important to the accessibility of the
CMAS is the accessibility of any CMASrelated consumer information in print or
electronic form. Providing information that
incorporates accessibility solutions for
individuals with special needs may also
bring benefits to the general population, not
just users with disabilities, as studies of
multimodal learning have shown. Listed here
are a variety of available resources that
present solutions to accessibility obstacles in
formats designed to easily educate and assist
publishers. The Web Accessibility Initiative
(WAI) develops strategies, guidelines, and
resources to help make the Web accessible to
people with disabilities. The following WAI
resources are intended to provide basic
information for people who are new to Web
accessibility. The W3C—World Wide Web
Consortium (W3C) Web Content Accessibility
Guidelines are available at https://
www.w3.org/WAI/.
The principles of universal design—
designing to meet the needs of as many users
as possible—provide a new dimension for
improving the usability of electronic
materials for everyone. The Carl and Ruth
Shapiro Family National Center for
Accessible Media at WGBH developed
Accessible Digital Media Design Guidelines
for Electronic Publications, Multimedia and
the Web, available at https://ncam.wgbh.org/
publications/adm/.
The above resources are provided for
informational purposes to ensure the
accessibility of all CMAS related print and
web content. It is not the intent of the
CMSAAC to make recommendations for
existing web content or web content not
associated with CMAS.
PO 00000
Frm 00042
Fmt 4701
Sfmt 4702
For future multimedia capabilities, if web
content is delivered to the mobile device,
consideration should be given to the
proposed World Wide Web Consortium
(W3C) Mobile Web Best Practices 1.0.
5.5.3 Subscriber CMA Opt-Out
Recommendations
As stated in the WARN Act, the CMA
subscriber opt out process may be supported
by a CMSP that elects to transmit.
Æ Opt-out is defined in Section
602(b)(2)(E) in the WARN Act as ‘‘the
capability of preventing the subscriber’s
device from receiving such alerts, or classes
of such alerts, other than an alert issued by
the President’’.12
Æ ‘‘Receiving such alerts’’ may also be
interpreted to ‘‘notify and display to the user
of such alerts’’ as the mobile device may
actually receive the alert but not present it to
the subscriber.
As noted in Section 5.1 above, there are
three classes of CMAS Message categories:
1. Presidential-level
2. Imminent threat to life and property
3. Child Abduction Emergency or ‘‘AMBER
Alert’’
Presidential-level messages must always be
transmitted and are not eligible for the optout procedure. Imminent Threat alerts are
messages where the CAP severity field is
Extreme or Severe, the CAP urgency field is
Immediate or Expected, and the CAP
certainty field is Observed or Likely. AMBER
Alert messages are considered a different
message classification and are treated
separately.
The CMSAAC recommends that CMSPs
shall offer their subscribers a simple opt-out
process that is based on the classification of
imminent threat and AMBER Alerts. Except
for presidential messages, which are always
transmitted, the process should allow the
choice to opt-out of:
• All messages,13
• All severe messages,14
• AMBER Alerts 15
Because of differences in the way CMSPs
and device manufacturers provision their
menus and user interfaces, CMSPs and
device manufacturers shall have flexibility
on how to present the opt-out choices to
subscribers.
5.6 Recommendations for CMAM
Transmissions
The CMSAAC recommends that the
CMAM be retransmitted into an effected area
until the alert expires. This will provide the
alert to those that might have missed the
initial broadcast alert, e.g., been in the
process of a voice call, those that might have
had their mobile device turned off when the
alert was issued or those that might be
entering the area after the alert was issued.
12 WARN
Act § 602(b)(2)(E).
messages will still be received.
14 Extreme messages, AMBER Alerts and
presidential messages will still be received
(Extreme messages are those messages where the
CAP severity field is Extreme, the CAP urgency
field is Immediate, and the CAP certainty field is
Observed or Likely).
15 All other messages will still be received.
13 Presidential
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
The interval and frequency of transmission
of CMAM performed by the CMSP is based
upon balancing the capabilities of the CMSP
specified delivery technology and various
factors, such as:
—Number of simultaneous active alerts
—Number of languages
—Mobile device battery life
—Latency from alert initiator to receipt by
first mobile device
—Notification to subscribers entering alert
area
—Limitations of delivery technology
—Configuration of delivery technology and
mobile devices
—Impact to normal call processing.
Therefore, the CMSAAC recommends that
the CMSP determine the frequency of
retransmissions based upon the
considerations and optimization of the above
mentioned factors.
5.7 Multi-Language CMAS Alerts
Recommendations
The WARN Act requires the CMSAAC to
submit to the Commission recommendations
‘‘for the technical capability to transmit
emergency alerts by electing commercial
mobile providers to subscribers in languages
in addition to English, to the extent practical
and feasible.’’ 16
Provision has been made in the CMAS
architecture to support language extensions,
for example the C interface contains fields to
identify language and character encoding (see
Section 10.4, below). Such extensions are
reserved for a time at which the engineering
impact of additional language sets is
understood. The biennial review committee
shall continue to study the feasibility of
broadcasting alerts in languages other than
English.
It is recognized that there is a strong desire
for the CMAS to support Spanish in addition
to English. A CMSP may choose to transmit
alerts received in languages other than
English based on the capabilities of the
technology the CMSP has deployed to
support CMAS alerts, the capabilities of the
mobile device, the CMSP’s policy, and the
definition of the single unified Federal policy
for the support of alerts in multiple
languages. In addition, the Alert Gateway
would need to be able to generate CMAM in
multiple languages.
The CMSAAC recommends that CMSPs
not be required to give notification in its
election to transmit alerts, at point of sale or
through any other means, or to the CMSP’s
subscriber base for not supporting the
transmission in languages other than English.
A fundamental requirement for the
optional support of languages other than
English is that the CMAM must be delivered
to the CMSP in the language that it is to be
delivered and in the CMAS format. At the
current time, there shall be no language
translation in the CMSP network or in the
mobile device. This requirement should be
reviewed as technology improvements are
developed.
The CMSAAC has analyzed the technical
feasibility of supporting multilanguage
CMAS alerts on the various delivery
16 WARN
Act § 603(c)(4)).
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
technologies and has determined that
support of languages other than English is a
very complex issue. Fundamentally the
existing air interfaces of CMSPs have
technical limitations and the support of
multiple languages may result in a significant
impact to capacity and latency due to these
limitations.
In addition, an important question is how
many languages should be considered? On a
National basis, only Spanish exceeds 1% of
households. On a local basis, however, there
are potentially more than 37 languages that
exceed 1% of households which would
require more than 16 different character sets
to be supported in the mobile device. This
raises issues such as character set limitations,
the amount of CMAS alert message traffic
that would need to be delivered in multilanguages, bandwidth limitations, increased
cost and complexity, mobile device
capabilities and deployment impacts.
Additional character sets to support multiple
languages also will potentially limit the
amount of data that can be transmitted; for
example, some character sets require 2 Bytes
per character versus 1 Byte per character, and
thus 90 characters available in the text profile
for a CMAM now reduces the text message
to 45 characters. Additional languages
increase the cost and complexity both in the
mobile device and in the CMSP network. At
the present time, the CMSAAC believes there
are fundamental technical problems to
reliably implement any languages in addition
to English.
5.8 CMAS Reception Control on Mobile
Devices
CMAS reception control is required where
subscribers and/or CMSPs should be allowed
to control the reception of CMAS alerts via
control of the delivery technology (e.g.,
broadcast) on a CMAS-capable mobile
device. The CMSAAC recognizes the WARN
Act requirements of not being able to opt-out
of Presidential messages. However, the
primary justifications for allowing a
subscriber and/or CMSP to control the CMAS
delivery technology capabilities on the
mobile devices include:
a. Providing the ability of not presenting
CMAS alert messages to users that may not
understand or may experience undue alarm
such as parents wanting to suppress this
service for young children or the elderly.
b. Disabling the broadcast capability when
traveling to locations where the CMAS
services are not desired or not supported and
thus preserving battery life in normal
circumstances.
c. In the presence of the CMSP radio signal,
potential savings on battery life, which may
be critical in an emergency or disaster
situation especially where power is not
available to recharge the mobile device.
d. Disabling the broadcast capability for
mobile devices that are being used for special
applications where the CMAS service is not
applicable such as a backup notification
method for in-home security systems.
e. Being able to disable the broadcast
capability for CMSPs that elect not to
transmit alerts in whole or in part.
Based upon the above, the CMSAAC
recommends:
PO 00000
Frm 00043
Fmt 4701
Sfmt 4702
587
1. The CMSP will have the capability to
enable or disable the broadcast capabilities or
CMAS functionality on any of their
associated mobile devices. This capability is
under CMSP control mechanisms such as
mobile device provisioning, and the CMSP
shall be required to give notification to the
subscribers as defined in Section 3.4 above.
2. The mobile device user may have the
capability on their mobile device to disable
the delivery technology for the CMAS alert
messages. The execution of this capability by
the subscriber shall require confirmation of
the action by the subscriber and there are no
additional CMSP notification requirements as
described in Section 3.4 above.
5.9
Roaming
The CMSAAC recommends that roaming
be supported only on an intra-technology
basis. For example:
1. Roaming GSM subscribers receive CMAS
alerts from GSM operators in the serving
market.
2. Roaming CDMA subscribers receive
CMAS alerts from CDMA operators in the
serving market.
3. If a CMSP elects not to support CMAS
alerts, subscribers from other CMSP will not
receive CMAS alert messages when roaming
onto that CMSP’s network.
4. If a CMSP elects not to support CMAS
alerts and subscribers from that CMSP roam
onto another CMSP network which does
support CMAS alerts, that roaming subscriber
will receive CMAS alert messages only if
their mobile device is configured to receive
CMAS alert messages with the delivery
technology of roamed-to CMSP network.
5. Inbound roamers may be supported if
the mobile device is configured for, is eligible
to receive and is technically capable of
receiving CMAS alert messages with the
delivery technology of the serving CMSP
network.
6
SERVICE PROFILES
The CMAS architecture and
recommendations are based upon the
principles of service profiles. Commercial
mobile operators may utilize any broadcast
technology to the mobile devices which
comply with the service profiles. The
following service profiles are defined
• Text Profile
• Streaming Audio Profile (future
capability)
• Streaming Video Profile (future
capability)
• Downloaded Multimedia Profile (future
capability)
The CMSAAC recommends that each
CMAS alert sent to the CMSP Gateway
contain, at a minimum, the attributes for the
text profile. Optionally, there may be
multiple streaming audio, streaming video,
and/or downloaded multimedia attributes
associated with the CMAS alert sent to the
CMSP Gateway.
Specifically, the following will be the
service profiles associated with a CMAS alert
sent to the CMSP Gateway:
• One Text Profile
• Zero or more Streaming Audio Profiles
• Zero or more Streaming Video Profiles
E:\FR\FM\03JAP2.SGM
03JAP2
588
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
• Zero or more Downloaded Multimedia
Profiles
The following section provides general
recommendations and conclusions on text,
audio, video, and multimedia resources.
6.1 Conclusions on Text, Audio, Video &
Multimedia Resources
1. The CMSAAC recommends that the
formats for future streaming audio, streaming
video, and multimedia be defined at point
where implementation and deployment of
these technologies have reached a point
where a standard set of formats can be
identified, e.g., at the initial biennial review
described in Section 5 above. The CMSAAC
also recommends that the alert initiation
systems do not implement any coding
formats for these types of resources until the
full impact to the end-to-end CMAS system
is understood.
2. The CMAS service profiles for text,
audio, video, and multimedia messages are
for the transmission of text data, audio files,
video files, and multimedia files and not for
the presentation of real-time content.
3. The CMSP networks are outside the
scope of the Trust Model of the government
alerting infrastructure.
4. The Alert Gateway is responsible for
collecting and assembling all text, audio,
video, and multimedia components of the
CMAS messages to be given to the CMSPs for
transmission.
a. If the CAP message includes a Resource
Element that includes an URI, it is not
expected that the CMSPs will be required to
retrieve the file specified by the URI. Rather,
the Alert Gateway will retrieve the associated
file during the collection and assembly
process for the CMAS alert message for
retrieval by the CMSPs.
b. Any audio, video, and multimedia files
collected for the CMAS alert messages must
be provided to the CMSPs in a standard set
of formats.
5. The CMSAAC recommends that the
government alerting infrastructure be aligned
with the capabilities and requirements as
defined under the CMAS.
a. The above referenced initial CMAS
service profiles are not capable of providing
real-time multimedia broadcasts including a
Presidential audio alert.
6.2
Text Profile
Support of the text profile is the minimum
requirement for any CMSP which elects to
support CMAS.
This information is passed from the Alert
Gateway to the CMSP Gateway and may
include attributes that are generated by the
CMAS alert originator.
TABLE 6–1.—TEXT PROFILE
[Service profile: Text_universal_service_profile]
Attribute name
Attribute definition
Purpose ................................
Maximum Payload Size .......
Common denominator for text messages.
120 bytes (As noted in Section 5.3.1, the biennial review committee shall review whether the character
limit profile may be increased.).
90 characters for an English language CMA encoded
with 7-bit encoding. (As noted in Section 5.3.1, the
biennial review committee shall review whether the
character limit profile may be increased.).
UTF–8 as defined in IETF RFC–3629 ............................
Maximum Displayable Message Size.
Data Coding Scheme ...........
6.3 Streaming Audio Profile (Future
Capability)
The streaming audio profile defines the
attributes for the support of streaming audio
Note
Size is estimated.
Languages other than English, or coding other then 7bit coding, will result in a change to the maximum
number of characters supported.
The text on the C interface is provided in UTF–8 format
which is capable of supporting text in English and
other languages. It is the responsibility of the CMSP
Gateway to translate to any character format encoding required by the CMSP selected delivery technology.
based CMAS alerts. Support of the streaming
audio profile is optional for any CMSP which
elects to support CMAS and is dependent on
the technology selected by the CMSP and
mobile device capabilities.
This information is passed from the Alert
Gateway to the CMSP Gateway and may
include attributes that are generated by the
CMAS alert originator.
TABLE 6–2.—STREAMING AUDIO PROFILE
[Service profile: Streaming_audio_service_profile]
Attribute definition
Purpose ................................
Maximum size ......................
Define service profile for streaming audio messages. ...
Based upon the authorized government entity policy ....
C Interface Data Coding
Scheme.
C interface Audio File Reference.
sroberts on PROD1PC70 with PROPOSALS
Attribute name
Identification of the standard format of the streaming
audio file being retrieved by the CMSP Gateway.
Issue of audio file transmissions remains to be addressed.
6.4 Streaming Video Profile (Future
Capability)
The streaming video profile defines the
attributes for the support of streaming video
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Note
Size of the streaming audio file is dependent on the file
type and encoding algorithms.
Size of CMAS alerts with streaming audio components
are much larger than text based CMAS alerts and,
therefore, could have greater impact to bandwidth requirements, message latency, etc.
See reference model.
The contents of this attribute are based upon the
streaming audio file being pulled by the CMSP Gateway from the Alert Gateway.
based CMAS alerts. Support of the streaming
video profile is optional for any CMSP which
elects to support CMAS and is dependent on
the technology selected by the CMSP and
mobile device capabilities.
PO 00000
Frm 00044
Fmt 4701
Sfmt 4702
This information is passed from the Alert
Gateway to the CMSP Gateway and may
include attributes that are generated by the
CMAS alert originator.
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
589
TABLE 6–3.—VIDEO PROFILE
[Service profile: Streaming_video_service_profile]
Attribute name
Attribute definition
Purpose ................................
Maximum Size .....................
Define service profile for streaming video alert messages.
Based upon the authorized government entity policy ....
C Interface Data Coding
Scheme.
C Interface Video File Reference.
Identification of the standard format of the streaming
video file being retrieved by the CMSP Gateway.
Issue of video file transmissions remains to be addressed.
6.5 Downloaded Multimedia Profile (Future
Capability)
The downloaded multimedia profile
defines the attributes for the support of
CMAS alerts with multimedia files (e.g.,
graphics, photos, maps, animation) which are
Note
Size of the streaming video file is dependent on the file
type and encoding algorithms.
Size of CMAS alerts with streaming video components
are much larger than text based CMAS alert messages and, therefore, could have greater impact to
bandwidth requirements, message latency, etc.
See reference model.
The contents of this attribute are based upon the
streaming video file being pulled by the CMSP Gateway from the Alert Gateway.
to be downloaded to the mobile device.
Support of the downloaded multimedia
profile is optional for any CMSP which elects
to support CMAS and is dependent on the
technology selected by the CMSP and mobile
device capabilities. The multimedia files for
download to the mobile device are
distributed using broadcast mechanisms
instead of point-to-point mechanisms based
upon by the CMSP selected technology.
This information is passed from the Alert
Gateway to the CMSP Gateway and may
include attributes that are generated by the
CMAS alert originator.
TABLE 6–4.—DOWNLOADED MULTIMEDIA PROFILE
[Service profile: Downloaded_multimedia_service_profile]
Attribute name
Attribute definition
Purpose ................................
Maximum Size .....................
Define service profile for CMAS alerts with multimedia
files for download to the mobile device.
Based upon the authorized government entity policy ....
C Interface Data Coding
Scheme.
C Interface Multimedia File
Reference.
Identification of the standard format of the multimedia
file being retrieved by the CMSP Gateway.
Issue of multimedia file transmissions remains to be addressed.
7 Mobile Device Functionality for CMAS
Alerts
This section describes the impact to the
mobile devices for the support of CMAS
alerts and organized into the following
topics:
• General Requirements of Mobile Device
Functionality
• Mobile Device Audio Attention Signal &
Vibration Cadence Recommendations
• CMAS Functionality on Mobile Device
• Impact to Mobile Device Battery Life
sroberts on PROD1PC70 with PROPOSALS
7.1 General Requirements of Mobile Device
Functionality
The CMSAAC recommends that the CMSP
and the mobile device vendors have the
flexibility in the design and implementation
of mobile devices in order to take the
maximum advantages of advances in mobile
device technologies and to account for the
evolution of mobile devices and the
capabilities of the future. The CMSAAC
further recommends that:
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Note
Size of the multimedia file for download is dependent
on the file type and encoding algorithms.
Size of CMAS alerts with multimedia components for
download to the mobile device are much larger than
text based CMAS alert messages and, therefore,
could have greater impact to bandwidth requirements, message latency, etc.
See reference model.
The contents of this attribute are based upon the multimedia file being pulled by the CMSP Gateway from
the Alert Gateway.
1. Mobile device behavior is outside the
scope of the WARN Act and, therefore, is not
subject to recommendations by the CMSAAC.
2. There be a common audio attention
signal and a common vibration alert cadence
for CMAM. (See Section 7.2 below.)
3. The functionality and features of the
mobile device after the receipt of the CMAM
(e.g., message storage, message expiration,
alert presentation visual interface, and user
acknowledgment to the mobile device of alert
messages) will be CMSP and mobile device
specific.
4. Legacy deployed mobile devices may not
be supported. At a minimum, new CMAS
functionality is needed on future mobile
devices.
a. New mobile devices will be introduced
by normal market mobile device lifecycle
replacement.
b. Some legacy pager devices may be able
to be updated with over the air programming.
5. Distribution of the CMAS alert messages
to the CMSP’s subscribers will be
unidirectional from the CMSP network to the
PO 00000
Frm 00045
Fmt 4701
Sfmt 4702
mobile device of the subscriber. There will
not be any acknowledgement or confirmation
of receipt from the mobile device.
6. CAP messages will not be delivered to
mobile devices of the subscribers.
7.2 Mobile Device Audio Attention Signal &
Vibration Cadence Recommendations
Currently most Americans are familiar
with the current EAS audio attention signals
on radios and televisions which have been in
use since the 1960s. Reproduction of this
audio attention signal on mobile devices is
the most recognizable method to notify the
American public of CMAS alert message.
The EAS uses a two tone system for audio
alerts which is a combination of 853Hz and
960Hz sine waves. For devices capable of
supporting dual tone EAS audio attention
signals, the CMAS audio attention signal
should sound as close to the EAS audio
attention signals as can be feasibility
achieved with the capabilities of the mobile
devices.
E:\FR\FM\03JAP2.SGM
03JAP2
590
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
The single tone for the NOAA warning
alarm tone for NOAA Weather Radios and
commercial broadcast stations is 1050Hz.
EAS audio attention signals on commercial
broadcast stations are 8 to 25 seconds in
duration and the NOAA warning alarm tone
is 8 to 10 seconds.
The CMSAAC recommends that temporal
patterns of the CMAS audio attention signal
should be supported if technologically
feasible. The recommended temporal pattern
of the CMAS audio attention signal is one
long tone of approximately 2 seconds
followed by two short tones of approximately
1 second each with approximately 1⁄2 second
gap between tones. The entire sequence is
repeated twice with approximately 1⁄2 second
between repetitions. Temporal patterns of the
CMAS audio attention signal are mobile
device manufacturer specific.
For devices that have polyphonic
capabilities, the CMSAAC recommends that
the audio attention signal consist of the two
EAS tones. For devices which have only
single frequency alert tone capability, it is
recommended that the CMAS audio attention
signal be in the low frequency range below
2 kHz.
The CMSAAC recommends that the
vibration cadence for the CMAS alert signal
be noticeably different from the default
cadence of the mobile device and should be
similar to the temporal pattern of the audio
attention signal and is mobile device
manufacturer specific.
If both CMAS audio and vibration cadence
alerts are available, the two modes do not
need to be activated simultaneously but will
follow the user’s settings in the mobile
device; if the mobile device supports dual
activation the signals will be simultaneous
according to user settings, but otherwise will
be separate signals.
The CMSAAC recommends that neither the
CMAS audio attention signal nor the
vibration cadence provided by the CMSP for
the CMAS alert should be selectable by the
subscriber for any mobile device functions.
However, the CMSAAC acknowledges that
there is no way to prevent the subscriber
from downloading a ring tone that emulates
the CMAS audio attention signal.
The CMSAAC recommended that the
CMAS audio attention signal and the
associated vibration cadence shall not be
used for any application other than CMAS.
The CMSAAC further recommended that the
CMAS audio attention signal and the
associated vibration cadence should be
protected via copyright and/or trademarks
and should be available for appropriate use
on free and non-discriminatory basis.
7.3 CMAS Functionality on Mobile Device
This section contains the CMSAAC’s
conclusions and recommendations regarding
the CMAS functionality on the mobile device
that would be needed to support CMAS
alerts.
1. If the end user has muted the mobile
device audio and alarms, the CMAS audio
attention signal will not be activated upon
receipt of a CMAS alert.
2. If the end user has deselected or turned
off the vibration capabilities of the mobile
device, the special emergency alert vibration
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
cadence will not be activated upon receipt of
a CMAS alert.
3. If the end user has both muted the
mobile device audio and alarms and has
deselected or turned off the vibration
capabilities of the mobile device, neither the
CMAS audio attention signal nor the special
emergency alert vibration cadence will be
activated upon receipt of a CMAS alert.
4. Subject to the limitations of the CMSP
selected broadcast technologies and the
mobile devices, the presentation of the
received CMAS alert message should take
priority over other mobile device functions
except for the preemption of an active voice
or data session.
5. If the end user does not acknowledge the
CMAS alert to the mobile device, the mobile
device should support the capability to
activate and deactivate the CMAS audio
attention signal and/or should activate and
deactivate the special emergency alert
vibration cadence, if mobile device has
vibration capabilities. The frequency and
interval of the activation and deactivation of
the CMAS audio attention signal and/or the
special emergency alert vibration cadence is
dependent on CMSP policies and mobile
device capabilities.
6. In order to minimize the possibility of
network congestion and false alerts, mobile
devices should not support any user interface
capabilities to forward received CMAS alerts,
to reply to received CMAS alerts, or to copy
and paste CMAS alert contents.
7. The presentation of CMAS alert
messages to the subscriber on the mobile
device should be distinguishable from any
other types of textual messages received by
the mobile device subject to mobile device
capabilities.
a. Color cannot be a required method for
distinguishing CMAS alert messages from
other types of text messages on the mobile
device since all mobile devices do not have
color display capabilities.
b. Color cannot be used as the sole method
for convening information. (See Section 5.5
above)
7.4 Impact to Mobile Device Battery Life
The CMSAAC recommends that the Alert
Aggregator support a policy of ensuring that
the aggregate CMAM rate does not adversely
impact mobile device battery life.
The CMSAAC recommends that the CMSPs
give consideration to modifications to
network infrastructure, mobile devices and/
or standards, and to the proper selection of
the criteria below, in order to limit the
reduction of battery life.
This analysis was limited in scope to text
based messages, and does not analyze the
impacts of other profiles, such as audio,
video or multimedia. The delta impact on
portable device battery life of text based alert
messages of CMAS depends upon the
following input criteria:
(a) Delivery Technology (GSM, UMTS,
CDMA2000 1x, Flex, Re-Flex, etc.).
(b) Initial system network parameters
before implementation of broadcast
messaging.
(c) Maximum latency to deliver the
message over the E interface.
(d) Retransmission interval.
PO 00000
Frm 00046
Fmt 4701
Sfmt 4702
(e) Number of languages supported.
(f) Number of alerts sent.
(g) Alert Duration, and number of times the
portable device alerts the user.
Each technology implements text broadcast
messaging differently. In addition, each
technology is deployed with different
hardware and software, as well as, different
standards releases. During the battery life
evaluation, these issues explain the wide
range of reported battery life impact of text
Broadcast Messaging. The battery life impact
of CMAS on a state of the art deployment of
infrastructure and portable devices targeting
optimized battery life could be as high as
40% or more.
When using older technology or different
network parameters, the impact to battery life
can be quoted as a lower percentage,
although battery life will be lower than the
optimized solution with cell broadcast
enabled.
Although there are limitations in today’s
implementation of Cell Broadcast, it can be
utilized for transmission of Emergency
Alerts. The impact to portable device battery
life can be managed through careful selection
of the above parameters. The high impact
parameters influenced by the CMSAAC are
maximum latency to deliver the message over
the E interface, Retransmission interval,
Number of languages supported, Number of
alerts sent, and Alert Duration. With
modifications to network infrastructure,
mobile devices and/or standards, and proper
selection of the above criteria, the reduction
of battery life can be less than 10% of today’s
capability for monitoring the Cell Broadcast
channel without sending alerts messages.
These modifications could potentially
adversely affect the timeline given in Section
12.2.1 below. When alert messages are sent,
e.g. a disaster situation with multiple alerts
sent from multiple agencies, the reduction of
battery life increases proportionally to the
number of messages sent and can approach
up to 40% of the battery life.
To design and deploy a system with the
performance described above, modifications
to the portable devices, network
infrastructure and/or standards are required.
These changes are scheduled in the proposed
timeline for deployment of CMAS.
8
Security for CMAS Alerts
8.1 Alert Interface & Aggregator Trust
Model
8.1.1 Trust Model Definitions
The following definitions are offered for
clarity and specificity.
• Identity—A trusted agent will verify the
identity of each individual that will be
requesting credentials.
• Responsibility—The individual will
have the duties of issuing public alerts and
warnings on behalf of their respective
jurisdiction.
• Jurisdiction—The area a person has
authority to send public alert and warning
messages.
• Authority—Any public servant that is
permitted by their jurisdiction to send a
public alert and warning message.
• Capability—The nominated individual
must demonstrate the knowledge of process,
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
content and policy pertaining to the issuance
of public alerts and warnings. The minimum
requirement shall be a national level
computer based training course. States and or
local jurisdictions may require further
training if they so desire.
• Credential—A specified form of evidence
that an individual has completed the
verification of identity, responsibility and
capability. This credential will allow the
individual to send or countersign a public
alert and warning message.
• Certified system—will support the Trust
Model and counter-signatory function to
send public alert and warning messages.
• Countersigned—A public alert and
warning message must be digitally signed by
two credentialed personnel for acceptance
into the CMAS.
• Originator—Can be a Federal, State,
Tribal, or local jurisdiction.
8.1.2 Trust Model Requirements
The CMSAAC makes the following
recommendations regarding Trust Model
requirements:
1. All messages will be attributed reliably
to an individual sender.
2. All messages will be accepted from
individuals holding a specified credential or
from a certified system which required
individual credentials.
3. All messages must be countersigned by
a second credentialed sender. All messages
not countersigned will be rejected and not be
sent. The sender must be notified if the
message was rejected for this reason.
4. The CMSAAC recommends that a
process be established by which credentials
can be certified upon demonstration of
identity, responsibility and capability.
5. Identity, responsibility and capability
must be recertified annually. All credentials
will expire in 12 months.
6. All messages entered into the system
will be logged, this log will be maintained for
a reasonable period of time to support an
audit.
7. The digital signatures will be bound to
the message and carried from the originator
to the Alert Gateway.
8. The message transport layer from the
originator to the Alert Gateway will utilize an
existing open non-proprietary transport
standard and shall be Internet Protocol based.
8.2 Alert Gateway Security Requirements
The CMSAAC recommends that the Alert
Gateway be protected against the potential
for misuse such as hoax emergency alerts,
illegal distribution of offensive content,
Denial of Service (DoS/DDoS) attacks and
SPAM. The CMSAAC recommends the
following requirements to achieve the
necessary level of security:
1. The Alert Gateway will be subject to and
administered in a manner consistent with the
Trust Model and shall be in compliance with
Federal Information Processing Standard
(FIPS) 199 and FIPS 200. The Alert Gateway
shall also be in compliance with security
requirements for National Critical
Infrastructure/Key Resources.
2. The Alert Gateway will be part of the
government alert distribution network. The
interface between the Alert Aggregator and
the Alert Gateway shall support the Trust
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Model specified in Section 8.1 above. The C
interface is outside the scope of the Trust
Model and therefore the Alert Gateway shall
support standardized authentication and
authorization mechanisms to interface with
the CMSP Gateways.
3. A single authorized source such as a
designated government agency, or their
authorized agent, will serve as the sole
operator for the Alert Gateway.
4. The Alert Gateway will authenticate the
source of all alert transactions. If the source
cannot be authenticated, the message will not
be sent and a warning issued to the Alert
Gateway’s monitoring system.
5. The Alert Gateway will inform the alert
originator via Alert Aggregator if the CMAS
message was not accepted by the CMSP
Gateway.
8.3 Reference Point C Security
The CMSAAC recommends that the
Reference Point C interface be IP based.
Therefore the security of the Reference Point
C interface should be based upon standard IP
security mechanisms such as VPN tunnels
and IPSEC functionality.
8.4 Reference Points D & E Security
The CMSAAC recommends that the
security of the Reference Points D and E be
based upon CMSP policies and upon the
capabilities of the CMSP selected delivery
technologies.
9
CMAS Reliability & Performance
The CMSAAC recommends that, to the
extent feasible, prior to the September 2008
CMSP Election, the statistical data on peak
and average alert traffic volume at least for
the period October 2007 thru August 2008 be
available to CMSPs to support the
engineering considerations for the CMSP
Gateway and air interfaces. This statistical
data needs to be available at the geo-targeted
areas defined in Section 5.4 above.
9.1 Alert Gateway Performance
Requirements
See Annex A—Anticipated Peak & Average
CMAS Traffic Volume for anticipated peak &
average CMAS traffic volume. The CMSAAC
makes the following recommendations
regarding Alert Gateway performance
requirements:
1. Based on available historical data
presented to the committee, and then
applying a 2X factor, it is estimated that no
more than 25,000 alert messages per year will
be delivered to the Alert Gateway for
transmission to the various CMSPs. It is also
assumed that peak rates as high as 12,000
alert messages per month and 6,000 alert
messages per day are possible. For a given
hour, it is also conceivable that there can be
an alert for every county in the U.S. and
therefore the Alert Gateway should be
capable of receiving and processing 3,000
alert messages per hour and a peak rate of 30
alert messages per second.
2. The Alert Gateway will have capabilities
to monitor the system utilization for capacity
planning purposes and it shall be scalable to
accommodate the need for additional
capacity.
3. The Alert Gateway will provide a
transmission control mechanism to buffer the
PO 00000
Frm 00047
Fmt 4701
Sfmt 4702
591
CMAM traffic upon receiving an overload
warning from the CMSP Gateway.
4. The Alert Gateway will provide the
capability for a CMSP or CMSP Gateway to
temporarily disable the transmission of all
CMAMs to the CMSP Gateway. While CMAM
delivery to CMSP Gateway has been stopped,
the Alert Gateway shall establish an alert
queue for the specific CMSP Gateway.
a. The CMSP Gateway will notify the Alert
Gateway to stop sending CMAM using an
error response as described in Section 10.4.6
below. Once the error condition has cleared,
the CMSP Gateway will notify the Alert
Gateway to restart CMAM delivery and retry
delivery of CMAMs in the queue if the
CMAMs have not expired.
b. The authorized government entity which
manages the Alert Gateway will establish a
process where an authorized CMSP
representative can provide notification of a
planned or unplanned outage of a CMSP
Gateway and during that outage period,
CMAMs are not delivered from the Alert
Gateway to that specific CMSP Gateway.
During a planned or unplanned outage, the
ability to support test message across the
Reference Point C interface will be supported
as defined in Section 10.4 below.
5. If the CMAM delivered over the
Reference Point C interface was rejected by
a CMSP Gateway due to congestion or
temporary transient error conditions, the
Alert Gateway will establish an alert queue
for the specific CMSP Gateway and retry
delivering it to the CMSP Gateway by a
configurable interval, e.g. every 30 seconds,
if the CMAM has not expired.
6. There are two logical queues per CMSP
Gateway, one logical queue for Presidential
alerts and another logical queue for all other
CMAMs. The processing of the Presidential
queue takes priority over the nonPresidential queue.
7. If an alert queue exists for a CMSP
Gateway, all incoming alerts shall be placed
into the queue based upon the time the
CMAM was received by the Alert Gateway.
8. The Alert Gateway will support separate
alert queues for each CMSP Gateway so that
queuing for one or more CMSP Gateway shall
not affect alerts delivery to all other CMSP
Gateways.
9. The Alert Gateway will be designed to
have the service availability of 99.999%.
10. System performance will be monitored
in real-time 24 hours a day seven days a
week to ensure all levels of service are met
and/or exceeded.
9.2 Alert Delivery Latency
The CMSAAC recommends that, since
latency will require experience in
deployment, end-to-end latency requirements
be addressed in the biennial review.
The CMSAAC recognizes the importance of
delivering CMAMs as quickly as possible
from the alert initiators to the transmission
within the alert area. The CMSAAC also
recognizes that there are operational
characteristics of the CMSP Infrastructure
which impact CMAM delivery latency. These
operational characteristics include the
following factors:
—Mobile device battery life impact
—Call processing impact
E:\FR\FM\03JAP2.SGM
03JAP2
592
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
—Capabilities of the delivery technology
—Message queues
—Number of languages
—Number of targeted cell sites/paging
transceivers for the alert area
—Geo-targeting processing
It is difficult to predict or model systems
that have not been designed, built, or
deployed.
9.3
CMAS End-to-End Reliability
sroberts on PROD1PC70 with PROPOSALS
The CMSAAC recommends that CMAS
system reliability from alert initiation to the
transmission of the CMAM over the CMSP
selected delivery technology meet telecom
standards for highly reliable systems.
In order to achieve, a feasible and practical
level of CMAS reliability on an end-to-end
basis:
• The CMSPs will process CMAS alerts on
a best effort.
• The CMAS alert message may be
retransmitted according to CMSP policies
and the capabilities of the CMSP selected
delivery technology.
Even though many components and
elements of the end to end CMAS solution
have high reliability, the over-all reliability of
CMAS is unpredictable for the following
reasons:
• RF transmissions can be subject to noise
and other interference or environmental
factors.
• The capabilities of the cellular
environment are not predictable especially in
a disaster environment. For example, it
cannot be predicted which and how many
cell sites will remain operational after a
disaster.
• The subscriber may currently be in a
location that does not have any RF signal.
• The subscriber’s mobile device may not
have any remaining power.
9.4 Message Logging
The CMSAAC recommends that the logs on
the Alert Gateway be used to identify
messages received by or rejected by the
CMSP Gateway. These logs will be accessible
by the alert originators and by the CMSPs.
These logs will be the only required audit
methods for the determination of which
CMAS messages were sent to the CMSPs.
The CMSAAC further recommends that,
upon receipt of an alert, the CMSP Gateway
will respond back to the Alert Gateway with
an acknowledgment that the alert message
was received or rejected. Message logging on
the CMSP Gateway is a function of the
system performance part of the Commercial
Mobile CMSP’s business, and will not be an
audit trail.
The CMSAAC recommends that there be
no requirements for the CMSP to retain logs
for any period of time.
9.4.1 Alert Gateway Logging
The CMSAAC makes the following
recommendations regarding Alert Gateway
logging:
1. The Alert Gateway will maintain a log
of messages with time-stamps that verify
when messages are received from the Alert
Aggregator and when the messages are
acknowledged or rejected by the CMSP
Gateway. The log for rejected messages will
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
include error codes for rejection as specified
in Section 10.4.6 below.
2. The Alert Gateway will maintain an
online log of active and cancelled alert
messages for 90 days.
3. The Alert Gateway will maintain
archived logs for a minimum of 36 months.
4. The Alert Gateway will provide CMSPs
access to online messaging logs and archived
logs for testing and troubleshooting purposes.
5. The Alert Gateway will generate
monthly system and performance statistics
reports based on CMA alerting category,
alerting originator, alerting area and other
alerting attributes.
6. The Alert Gateway will provide the
capability for a CMSP to temporarily disable
the transmission of all CMAMs to the CMSP
Gateway. This event will be captured in the
log file. Cancellation of the event should be
noted in the log file as well.
9.5 CMAS Testing
End-to-end testing of the CMAS is defined
to be testing from the Alert Initiator to the
CMSP Gateway. This testing will verify the
A, B, and C reference points, as well as the
function of the Alert Aggregator, Alert
Gateway, and CMSP Gateway. It is
undesirable to send test messages over the
CMSP infrastructure to the mobile devices as
these messages could cause considerable
confusion to the end user, as well as utilizing
CMSP network resources.
Using real event codes for testing purposes
poses the risk of unintentionally alarming
and confusing recipients. For this reason, and
to insure that a test message does not
propagate to the CMSP subscriber base, the
CMSAAC recommends that all end-to-end
testing be indicated using the CAP status
element with a value of ‘‘test’’, which shall
be mapped to a test message over Reference
Point C. Upon receipt of a test message, the
CMSP Gateway will respond with an
acknowledgment of receipt of the message
and log receipt of the message according to
CMSP policy.
The CMSAAC recommends that the CMSP
Gateway support receiving a test message
from the Alert Gateway for testing Reference
Point C. This test message shall not be
delivered to the CMSP Infrastructure nor
broadcast to subscribers.
The CMSAAC recommends that the CMSP
Gateway support the receipt and processing
of Alert Gateway keep-alive test messages
periodically. The frequency shall be
configurable based on policy to be
determined by the authorized government
entity and the CMSPs.
The CMSAAC recommends that the keepalive test messages not be sent if there are
real messages to be sent.
9.5.1 General CMAS Testing
Recommendations
An important part of a successful CMAS
will be the ability to effectively test and
troubleshoot the various components and
interfaces.
The CMSAAC recommends that this test
and troubleshooting capability be integrated
into the architecture and protocol of the
CMAS up front, to maximize effectiveness.
The CMSAAC recommends the following
primary aspects of CMAS Testing and
PO 00000
Frm 00048
Fmt 4701
Sfmt 4702
Troubleshooting capability to allow thorough
testing and troubleshooting of the end-to-end
CMAS without wearying the public:
1. Provision for testing of the CMAS,
including the delivery mechanisms, without
requiring all subscribers to see a test message.
a. This might be accomplished by
providing signaling in the application layer
which indicates a test message—which
would not be displayed by ‘normal
terminals’, but could be displayed by ‘test
terminals’. CMSPs could configure which
devices were ‘test terminals’.
b. Provide the ability to send test messages
to a single CMSP/network without impact to
other CMSPs.
c. Provide the ability to test the CMAS up
to the CMSP Gateway without impacting the
CMSP infrastructure.
2. Provide CMSP access to the CMAM logs
from the Alert Gateway.
3. Messages used for testing purposes shall
be clearly differentiated from messages for
actual events.
9.5.2 Alert Gateway Testing
The CMSAAC recommends that the Alert
Gateway support several types of testing:
a. Functional testing for the C interface (not
expected to be sent to the subscribers)
b. Connection testing for new CMSP
The CMSAAC further recommends the
following requirements for Alert Gateway
testing:
1. The Alert Gateway will support
initiating a test message for each service
profile implemented for Reference Point C
upon request by a particular CMSP. The test
message will only be sent to a specific CMSP
Gateway. The message will not be broadcast
to subscribers.
2. The Alert Gateway will support
initiating a test message for each service
profile implemented for Reference Point C for
all CMSP Gateways. The message will not be
broadcast to subscribers.
3. The Alert Gateway will support keepalive test messages periodically over the C
interface. The frequency will be configurable
based on policy to be determined by the
authorized government entity and the
CMSPs. The keep-alive test messages will not
be sent if there are real messages to be sent.
4. All test messages for the C interface will
be clearly marked and identified as test
messages.
10 Interface Protocols for CMAS Alerts
The following two interfaces are applicable
for the support of CMAS alerts in the CMSP
networks:
• Alert Gateway—CMSP Interface which is
Reference Point C.
• CMSP—Mobile Device Interface for
CMAS alert content which is Reference Point
E.
Both of these interfaces are defined in this
section.
10.1 Reference Point A Protocol
The CMSAAC recommends that Reference
Point A interface requirements consist of the
following:
1. The message sent to the Alert Aggregator
must consist of one of the following:
a. A valid CAP 1.1 message with all
mandatory elements.
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
•
•
•
•
•
•
•
•
•
•
•
•
Message ID
Sender ID
Sent Date/Time
Message Status
Message Type
Scope
Event Category
Urgency
Severity
Certainty
Resource Description
Area Description—A FIPS geo-code, a
polygon or circle (WGS–84 format) will be
used to support the area description.
2. The Alert Aggregator will provide a
mechanism to validate the identity of the
individual sending the message to allow nonrepudiation.
3. The implementer of the Alert Aggregator
will provide a documented, non-proprietary,
specification for transport that will support
appropriate security and reliability.
sroberts on PROD1PC70 with PROPOSALS
10.2 Reference Point B Protocol
The CMSAAC recommends that Reference
Point B interface requirements consist of the
following:
1. The implementer of the Alert Gateway
will provide a documented non-proprietary
specification for the B interface which will
support appropriate security and reliability.
10.3 Alert Gateway Interfaces & Mapping
Requirements
10.3.1 Alert Gateway Interface
Requirements
The CMSAAC recommends the following
requirements for the Alert Gateway
interfaces:
1. The Alert Gateway will support an open,
non-proprietary interface to the Alert
Aggregator (e.g. IP).
2. The Alert Gateway will initially support
CAP v1.1 as the application layer protocol for
communicating with the Alert Aggregator.
3. The Alert Gateway will uniquely
identify each CMSP Gateway identified by a
unique IP address or domain name.
4. The Alert Gateway will support the ‘‘C’’
interface protocol as defined in Section 10.4
below.
5. The Alert Gateway will support all
CMAM formats that can be delivered to
CMSP Gateway.
6. The Alert Gateway will support the
common service profile formats as referred to
in Section 6 above for text, audio, video and
multimedia transmission of alert messages to
the CMSP Gateways.
7. The Alert Gateway will support
receiving acknowledgment from the CMSP
Gateway that the CMAM has been received
or rejected by the CMSP Gateway.
8. If any mandatory parameter/attribute is
not included in the CAP message sent over
the B interface, the Alert Gateway will use a
default parameter value if available, or reject
the CAP message if a default parameter value
is not available.
10.3.2 Alert Gateway Interface Mapping
Requirements
The Alert Gateway will map the CMAMs
received in CAP format into the CMAC
format supported by the CMSP Gateway.
1. If eventCode = ‘‘EAN’’, the CMAM will
be handled as a Presidential Alert. The Alert
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Gateway will not forward messages with
eventCode = ‘‘EAT’’ or ‘‘NIC’’ to the CMSP
Gateway.
2. The Alert Gateway will deliver CMAMs
using the same language as issued by the
alert originator and will not do language
translation as a gateway function.
3. Each CMAM will only include one
language. The CMA issued in multiple
languages will be issued by separate
messages.
4. All CMAM alert, update and
cancellation messages will come only from
the alert originators, including Presidential
Alert. The Alert Gateway will pass these
messages to the CMSP Gateway. The Alert
Gateway is not required to generate alerts,
alert updates and/or cancellations.
5. The Alert Gateway will not alter the
content of text alert messages, with the
exception of
a. If CAP expires is not available, the
default parameter value of one hour shall be
used.
b. Constructing the text alert message using
CAP elements such as category, eventCode
and responseType. The algorithm for
constructing the text alert message is
described in Section 5.3 above.
6. For Presidential Alert, the Alert Gateway
will use the following CAP elements to
construct the message:
a. Use CAP parameter (with valueName =
CMAMtext), if available and less than the
maximum CMA message length limit. If not,
then
b. Use Alert Gateway generated automatic
text: ‘‘The President has issued an emergency
alert. Check local media for more details.’’
7. For AMBER Alert, the Alert Gateway
will use the following CAP elements to
construct the message:
a. Use CAP parameter (with valueName =
CMAMtext), if available and less than the
maximum CMA message length limit. If not,
the Alert Gateway will reject the message.
8. For alerts other than the Presidential
Alert or AMBER Alert, the Alert Gateway
will support free-format text generation or
automatic text generation.
9. For free-format text generation, the Alert
Gateway will use the CAP parameter (with
valueName = CMAMtext) to construct the
message. If the CAP parameter (with
valueName = CMAMtext) is not available or
exceeds the maximum CMA message length
limit, the Alert Gateway will reject the
message.
10. For automatic text generation, the Alert
Gateway will support the following rules to
construct the message:
a. What’s happening: The Alert Gateway
will use the expanded text as defined in
Table 5.1 for the CAP eventCode element if
available. If eventCode is not provided, the
Alert Gateway will use the expanded text as
defined in Table 5.1 for the CAP category
element.
b. Area Affected: The Alert Gateway will
use the phrase ‘‘in this area’’.
c. Recommended action: The Alert
Gateway will use the CAP responseType
element if available. If responseType is not
provided, the Alert Gateway will not include
this information.
d. Area Affected: The Alert Gateway will
use the phrase ‘‘in this area’’.
PO 00000
Frm 00049
Fmt 4701
Sfmt 4702
593
e. Expiration time with time zone: The
Alert Gateway will translate the time
according to Table 5.1 for the CAP expires
element if provided. The Alert Gateway will
use the time zone provided in the CAP
expires element or may use the time zone in
the affected area. If not provided, the Alert
Gateway will use one hour from the current
time as a default. If the affected area has more
than one time zone, the Alert Gateway will
use one of the time zones.
f. Sending Agency: The Alert Gateway will
translate it according to Table 5.1 for the CAP
sender element. The translated sending
agency should not exceed the maximum
length of 12 characters in order to fit into the
maximum CMA message length limit. The
translated sending agency will be truncated
to 12 characters if it causes the constructed
message to exceed the maximum CMA
message length limit.
11. If the CAP message received by the
Alert Gateway is not formatted correctly, the
Gateway will reject the message and inform
the alert originator.
12. If a CAP message contains multiple
INFO blocks with the same headline but
different area elements, the Alert Gateway
will collapse it into a single CMAM with a
single INFO block and multiple area
elements before sending it to the CMSP
Gateway.
13. If a CAP message contains multiple
INFO blocks with the different headlines, the
Alert Gateway will create separate CMAM
with each INFO block. The Alert Gateway
will process the INFO blocks in the order
contained in the CAP message.
14. The Alert Gateway will not do
translations of the character sets.
15. The Geo-mapping of targeted area (cell
sites) will be the responsibility of CMSPs and
not a function of the Alert Gateway.
16. The Alert Gateway will provide the
geo-targeting information over Reference
Point C in accordance with the CMSP profile
stored within the Alert Gateway.
17. The Alert Gateway will provide
Geocode as specified in Section 10.4 below
to the CMSP Gateway.
18. The Alert Gateway will translate
latitude/longitude coordinates into
appropriate State or County Geocode if no
State or County Geocode is provided by the
alert originator.
19. The Alert Gateway will not be required
to translate State or County Geocode into
latitude/longitude coordinates.
20. The Alert Gateway will specify an
agreed upon maximum number of latitude/
longitude coordinates per polygon to be sent
to the CMSP Gateway.
21. If Geocode, polygon or circle is not
provided for a Presidential Alert, the Alert
Gateway will use ‘‘Nation wide’’ by default.
22. If Geocode, polygon or circle is not
provided for any non-presidential alert or
update, the Alert Gateway will reject the
message and return an error to the alert
originator.
23. For audio, video and multi-media
CMAMs, if the CAP message includes the
associated files, the Alert Gateway will
a. Re-format, if necessary, the associated
files into standardized format as specified in
the associated service profile (see Section 6
above).
E:\FR\FM\03JAP2.SGM
03JAP2
594
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
b. Store the associated files on the Alert
Gateway to be retrieved by the CMSP
Gateways.
c. Send the message with proper URL so
that CMSP Gateways can retrieve the files if
they so choose.
24. For audio, video and multi-media
CMAMs, if the CAP message includes only
the URL but not the associated files, the Alert
Gateway will
a. Retrieve the associated files from the
URL in the CAP message.
b. Re-format, if necessary, the associated
files into standardized format as specified in
the associated service profile (see Section 6
above).
c. Store the associated files on the Alert
Gateway to be retrieved by the CMSP
Gateway.
d. Send the message with proper URL so
that CMSP Gateway can retrieve the files if
they so choose.
25. The Alert Gateway, via Reference Point
C, will always provide the CMSP Gateway,
the CMAC_geocode as defined in Section
10.4 below. Additionally, if available, the
Alert Gateway will provide one or more of
the following parameters to identify the alert
area: CMAC_polygon, CMAC_circle or
CMAC_gnis format.
26. The Alert Gateway will be responsible
to generate the CMAC geocode(s)
corresponding to the alert area from the CAP
‘‘area’’ element. The CMAC geocode(s)
corresponding to the alert area will be
generated from either the area described by
the polygon or circle, conversion of the
SAME code or ZIP code for the alert area, or
using the FIPS value if specified in the
original CAP alert message.
27. If the original CAP message does not
contain a polygon, circle, or geocode, the
Alert Gateway will reject the message unless
the message originator was the President, in
which case the alert area will be assumed
Nationwide in the absence of the area
information.
28. CAP will be the protocol used on the
‘‘B’’ interface to carry the CMAM into the
Alert Gateway. Not all the elements and
values allowed by CAP are useful for
CMAMs. Also some elements are optional in
CAP but required by CMAMs. The Alert
Gateway will apply the following mapping
and filtering rules for all the messages
received via the ‘‘B’’ interface as shown in
Table 10–1. The following is a description of
the column shown in Table 10–1:
Column 1: Lists the CAP element.
Column 2: Lists the code values applicable
to CMAMs.
Column 3: Lists the filtering and mapping
rules to be used by the Alert Gateway. ‘‘Pass’’
means the element and code value will be
passed from the ‘‘B’’ interface to the ‘‘C’’
interface. ‘‘Mapped’’ means the CAP element
and code value will be mapped into the
appropriate CMAC attribute. ‘‘Reject’’ means
the Alert Gateway will reject the CAP
message received from the ‘‘B’’ interface and
no message will be sent over the ‘‘C’’
interface. ‘‘Ignored’’ means the CAP element
is not applicable to CMAM and will be
ignored by the Alert Gateway. ‘‘Generated’’
means the Alert Gateway will generate the
appropriate CMAC elements and attributes.
Column 4: Lists the corresponding ‘‘C’’
interface CMAC elements as defined in
Section 10.4 below.
TABLE 10–1.—PARAMETER MAPPING FROM ‘‘B’’ INTERFACE CAP MESSAGE IN TO ‘‘C’’ INTERFACE CMAC MESSAGE
(CMA) Permitted values
Alert gateway filtering rules
CMAC element
N/A .................................................
N/A .................................................
alert ................................................
identifier (free format) ....................
.......................................................
.......................................................
N/A ................................................
.......................................................
sender ............................................
sent ................................................
status .............................................
.......................................................
.......................................................
‘‘Actual’’ ‘‘Exercise’’ ‘‘System’’
‘‘Test’’.
‘‘Alert’’ ‘‘Update’’ ‘‘Cancel’’ ‘‘Error’’
source ............................................
scope .............................................
N/A ................................................
‘‘Public’’ .........................................
restriction .......................................
.......................................................
addresses ......................................
.......................................................
code ...............................................
note ................................................
references ......................................
.......................................................
.......................................................
.......................................................
Generated by the Alert Gateway ..
Generated by the Alert Gateway ..
Ignored ..........................................
Mapped from the free format into
a 2 octet binary number.
Pass ..............................................
Mapped into UTC format ..............
Pass with permitted values; Reject message with ‘‘Draft’’.
Pass with permitted values; Reject message with ‘‘Ack’’.
Ignored.
Reject message if ‘‘Public’’ is not
in field..
Reject message if this element is
included.
Reject message if this element is
included.
Ignored ..........................................
Pass ..............................................
Mapped from the free format into
a 2 octet binary number.
CMAC protocol version.
CMAC sending Alert Gateway id.
N/A
CMAC_message_identifier
(2
octet binary number).
CMAC_sender.
CMAC_sent_date_time.
CMAC—status.
msgType ........................................
incidents .........................................
N/A .................................................
info .................................................
language ........................................
category .........................................
event ..............................................
responseType ................................
N/A ................................................
.......................................................
.......................................................
.......................................................
.......................................................
N/A ................................................
All but ‘‘Assess’’ ............................
urgency ..........................................
sroberts on PROD1PC70 with PROPOSALS
CAP element
‘‘Immediate’’ ‘‘Expected’’ ..............
severity ...........................................
‘‘Extreme’’ ‘‘Severe’’ .....................
certainty .........................................
‘‘Observed’’ ‘‘Likely’’ .....................
audience ........................................
N/A ................................................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
PO 00000
Frm 00050
Fmt 4701
Ignored ..........................................
Generated by the Alert Gateway ..
.......................................................
Pass ..............................................
Mapped .........................................
Ignored ..........................................
Reject message with ‘‘Assess’’ in
field, pass all others.
Pass with permitted values or rejecting message with other values.
Pass with permitted values or rejecting message with other values.
Pass with permitted values or rejecting message with other values.
Ignored ..........................................
Sfmt 4702
E:\FR\FM\03JAP2.SGM
CMAC_message_type.
N/A.
N/A.
N/A.
N/A.
CMAC_cancel_error_node.
CMAC_referenced_message_
identifier (2-octet binary number).
N/A.
CMAC_original_cap_alert_uri.
Ignored.
CMAC_text_language.
CMAC_category.
N/A.
CMAC_response_type.
CMAC_urgency.
CMAC_severity.
CMAC_certainty.
N/A.
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
595
TABLE 10–1.—PARAMETER MAPPING FROM ‘‘B’’ INTERFACE CAP MESSAGE IN TO ‘‘C’’ INTERFACE CMAC MESSAGE—
Continued
CAP element
(CMA) Permitted values
Alert gateway filtering rules
eventCode ......................................
‘‘EAN’’ ...........................................
‘‘CAE’’ ...........................................
eventCode ......................................
effective ..........................................
onset ..............................................
expires ...........................................
.......................................................
N/A ................................................
N/A ................................................
.......................................................
senderName ..................................
headline .........................................
.......................................................
.......................................................
description ......................................
N/A .................................................
N/A .................................................
N/A .................................................
N/A ................................................
ASCII 7-bit ....................................
Less than 90 characters ...............
.......................................................
instruction .......................................
web ................................................
N/A ................................................
.......................................................
contact ...........................................
parameter .......................................
N/A ................................................
N/A ................................................
resource .........................................
resourceDesc .................................
mimeType ......................................
size .................................................
uri ...................................................
N/A ................................................
.......................................................
.......................................................
.......................................................
.......................................................
derefUri ..........................................
degest ............................................
area ................................................
areaDesc ........................................
polygon ..........................................
circle ...............................................
geocode .........................................
N/A ................................................
.......................................................
N/A ................................................
.......................................................
.......................................................
.......................................................
.......................................................
geocode .........................................
.......................................................
altitude ...........................................
ceiling .............................................
N/A ................................................
N/A ................................................
Map ‘‘EAN’’ to ‘‘Presidential’’; .......
Map ‘‘CAE’’ to ‘‘Child Abduction’’;
Map other values to ‘‘No special
handling’’.
Mapped .........................................
Ignored ..........................................
Ignored ..........................................
Passed; Reject message if already expired;.
Apply default value of one hour if
not provided.
Mapped .........................................
Passed
conditionally
when
eventCode= ‘‘EAN’’ or ‘‘CAE’’;.
Ignored when eventCode has
other values.
Ignoring .........................................
Ignoring .........................................
Generated by the Alert Gateway ..
Generated by the Alert Gateway
as specified in Section 5.5.
Ignored ..........................................
Mapped to a local link on the Alert
Gateway.
Ignored ..........................................
Passed
conditionally
when
eventCode= ‘‘EAN’’ or ‘‘CAE’’;.
Passed
conditionally
when
eventCode has other values
and parameter valueName =
‘‘CMAMtext’’; Ignored otherwise.
Ignored ..........................................
Mapped .........................................
Mapped .........................................
Mapped .........................................
Mapped to a local link on the Alert
Gateway.
Ignored ..........................................
.......................................................
Ignored ..........................................
Passed ..........................................
Passed ..........................................
Passed ..........................................
Passed, or generated based on
polygon and/or circle.
Generated based on polygon and/
or circle.
Ignored ..........................................
Ignored ..........................................
sroberts on PROD1PC70 with PROPOSALS
29. If an incoming CAP message fails the
Alert Gateway validation or filtering rules, an
error message will be sent over the ‘‘B’’
interface to the alert originator. The error
message may contain additional information
in the ‘‘note’’ element. The ‘‘note’’ element in
the error response to the alert originator may
contain multiple error messages. The
following are some examples of error
responses.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
a. CMA error #1: Unsupported code value
of ‘‘’’ in element ‘‘’’
(e.g. scope = ‘‘Private’’)
b. CMA error #2: Missing required element
‘‘’’ (e.g. element Y =
eventCode)
c. CMA error #3: Unsupported element
‘‘’’ (e.g. element Z =
restriction)
PO 00000
Frm 00051
Fmt 4701
Sfmt 4702
CMAC element
CMAC_special_handling.
CMAC_event_code.
N/A.
N/A.
CMAC_expires_date_time.
CMAC_sender_name.
CMAC_text_alert_message.
CMAC_text_alert_message.
CMAC_text_encoding.
CMAC_text_message_length.
CMAC_text_alert_message.
N/A.
CMAC_web_link.
N/A.
CMAC_text_alert_message.
N/A.
CMAC_resource_description.
CMAC_mime_type.
CMAC_resource_size.
CMAC_uri.
N/A.
Ignored
N/A.
CMAC_area_description.
CMAC_polygon.
CMAC_circle.
CMAC_cmas_geocode.
CMAC_cmas_gnis.
N/A.
N/A.
d. CMA error #4: Text message length
exceeds maximum limit.
10.4
Reference Point C Protocol
The C reference point is the interface from
the Alert Gateway to the CMSP Gateway. The
C reference point is used to map the CAP
elements into the CMSP protocol on the C
reference point (‘‘CMAC’’), as follows:
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
sroberts on PROD1PC70 with PROPOSALS
10.4.1 Structure of the CMA ‘‘C’’ Reference
Point Protocol
The CMSAAC recommends that each
CMAC Alert message consist of the following
segments:
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
—CMAC Alert Attributes segment
—CMAC Alert Info segment
—CMAC Alert Area segment
—CMAC Alert Resource segment
The CMSAAC recommends that the
PO 00000
Frm 00052
Fmt 4701
Sfmt 4702
CMAC Alert Message document object
model be as follows:
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.016
596
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
BILLING CODE: 6712–01–C
The CMSAAC recommends that a CMAC
Alert Message must contain:
one CMAC_Alert_Attributes segment
one or more CMAC_Alert_Info segments
one or more CMAC_Alert_Area segements.
The CMAC_Resource segment is optional
for future use in streaming audio, streaming
video, and multimedia CMAs.
10.4.2
597
CMAC Data Dictionary
10.4.2.1
CMAC_Alert_Attributes Segment
TABLE 10–2.—CMAC_ALERT_ATTRIBUTES SEGMENT
Mandatory/
optional/
conditional
M ................
CMAC_protocol_v version ........... M ................
CMAC_sending_a alert_gateway_ M ................
id.
CMAC_message_i identifier ....... M ................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC definition
(1) Surrounds CMAC alert message subelements.
(2) MUST include the xmlns attribute referencing the CMAC URN as the namespace, e.g.:
[sub-elements]
cmac:CMAC_alert>
(3) In addition to the specified subelements, MAY contain one or more
blocks.
The version of the CMAC protocol. Used by the CMSP Gateway only. Specified by the Alert
Gateway.
URI of the Alert Gateway sending the CMAC message. Specified by thet Alert Gateway.
A 2-octet binary value uniquely identifying this message, assigned by the Alert Gateway and
derived from the CAP identifier element. This element is sent to the mobile device.
PO 00000
Frm 00053
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.017
CMAC_alert ................................
sroberts on PROD1PC70 with PROPOSALS
CMAC element
598
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
TABLE 10–2.—CMAC_ALERT_ATTRIBUTES SEGMENT—Continued
CMAC element
Mandatory/
optional/
conditional
CMAC_referenced_message_
identifier.
C ................
CMAC_special_handling ............
O ................
CMAC_sender ............................
M ................
CMAC_sent_date_time ..............
M ................
CMAC_status .............................
M ................
CMAC_message_type ...............
M ................
CMAC_note ................................
O ................
CMAC_original_cap_alert_uri .....
M ................
10.4.2.2
CMAC_Alert_Info Segment
Multiple occurrences are permitted within
the CAP from the alert originator; the
CMSAAC recommends that each occurrence
CMAC definition
A 2-octet binary value uniquely identifying a referenced CMAM, assigned by the Alert Gateway.
Required for an Update, Cancel or Ack CMAC_message_type. Derived from the CAP references element.
Specifies if this alert message requires special handling. Specified by the Alert Gateway, derived from CAP elements.
Code Values: ‘‘Presidential’’ ‘‘Child Abduction’’ ‘‘No Special Handling.’’
Identifies the originator of this alert. Used by the CMSP for logging purposes only. Alert Gateway uses the CAP sender element to populate this element.
The date and time the message is sent by originator in UTC in XML dateTime format. Derived
from the CAP sent element.
Alert Gateway uses the CAP status element to populate this element. Code Values:
‘‘Actual’’—Actionable by all targeted recipients.
‘‘Exercise’’—Actionable only by designated exercise participants, for CMSP use.
‘‘System’’—For messages that support alert network internal functions. In addition this is used
for the ‘‘keep alive’’ message between the Alert Gateway and the CMSP Gateway.
‘‘Test’’—Technical testing of the C Reference Point only, for CMSP Gateway use only.
Alert Gateway uses the CAP msgType element to populate this element. Code Values:
‘‘Alert’’—Initial information requiring attention by targeted recipients.
‘‘Update’’—Updates and supercedes the earlier message(s) identified in
‘‘Cancel’’—Cancels the earlier message(s) identified in
‘‘Ack’’—Acknowledges receipt and acceptance of the message(s) identified in < CMAC_referenced_message_identifier > additional explanation may appear in
‘‘Error’’ indicates rejection of the message(s) identified in explanation SHOULD appear in
Optional element. Used for CMSP logging purposes for a cancel or error message type, or to
provide a response back to the Alert Gateway. Alert Gateway uses the CAP note element to
populate this element on messages from the Alert Gateway to the CMSP Gateway. The
CMSP Gateway uses this element on messages to the Alert Gateway.
This element contains the uri where the CMSP may retrieve the original complete CAP version
of the alert from the Alert Gateway. Specified by the Alert Gateway.
be a separate CMAM from the Alert Gateway.
The CMSAAC further recommends that each
language be sent as a separate CMAM with
a unique message identifier. It is anticipated
that a separate CMAS_Alert_Info element
with associated sub-elements will be created
for the CMAMs to be given to the CMSPs for
broadcast via the CMSP selected technologies
consistent with the requirements and
procedures defined by the CMSAAC.
TABLE 10–3.—CMAC_ALERT_INFO SEGMENT
CMAC element
Mandatory/
optional/
conditional
CMAC_alert_info ........................
sroberts on PROD1PC70 with PROPOSALS
CMAC_category .........................
M ................
CMAC_event_code ....................
O ................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC definition
(1) Only a single occurrence is permitted within a single . If there are multiple
‘‘info’’ segements in the original CAP message, the Alert Gateway shall format as separate
CMAC messages each with a unique identifier.
(2) In addition to the specified subelements, MAY contain one or more
blocks and/or one or more blocks.
Alert Gateway uses the CAP category element to populate this element. Code Values used by
CMSP Gateway only:
‘‘Geo’’—Geophysical (inc. landslide).
‘‘Met’’—Meteorological (inc. flood).
‘‘Safety’’—General emergency and public safety.
‘‘Security’’—Law enforcement, military, homeland and local/private security.
‘‘Rescue’’—Rescue and recovery.
‘‘Fire’’—Fire suppression and rescue.
‘‘Health’’—Medical and public health.
‘‘Env’’—Pollution and other environmental.
‘‘Transport’’—Public and private transportation.
‘‘Infra’’—Utility, telecommunication, other non-transport infrastructure.
‘‘CBRNE’’—Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack.
‘‘Other’’—Other events.
Alert Gateway uses the CAP eventCode element to populate this element. Optional element
used by the CMSP Gateway only.
PO 00000
Frm 00054
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
599
TABLE 10–3.—CMAC_ALERT_INFO SEGMENT—Continued
CMAC element
Mandatory/
optional/
conditional
O ................
CMAC_severity ..........................
M ................
CMAC_urgency ..........................
M ................
CMAC_certainty .........................
M ................
CMAC_expires_date_time ..........
sroberts on PROD1PC70 with PROPOSALS
CMAC_response_type ...............
M ................
CMAC_sender_name .................
O ................
CMAC_text_language ................
M ................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC definition
A system-specific code for event typing, in the form: , valueName, value,
CMAC_event_code> where the content of ‘‘CMAC_valueName’’ is a user assigned string
designating the domain of the code, and the content of ‘‘value’’ is a string (which may represent a number) denoting the value itself (e.g., CMAC_valueName =‘‘SAME’’ and
value=‘‘TOR’’).
Values of ‘‘CMAC_valueName’’ that are acronyms SHOULD be represented in all capital letters
without periods (e.g., SAME).
The following SAME codes are supported in CMAS:
Æ Civil Danger Warning CDW
Æ Civil Emergency Message CEM
Æ Evacuation Immediate EVI
Æ Hazardous Materials Warning HMW
Æ Law Enforcement Warning LEW
Æ Local Area Emergency LAE
Æ Nuclear Power Plant Warning NUW
Æ Radiological Hazard Warning RHW
Æ Shelter in Place Warning SPW
Æ Avalanche Warning AVW
Æ Blizzard Warning BZW
Æ Child Abduction Emergency CAE
Æ Coastal Flood Warning CFW
Æ Dust Storm Warning DSW
Æ Earthquake Warning EQW
Æ Fire Warning FRW
Æ Flash Flood Warning FFW
Æ Flood Warning FLW
Æ High Wind Warning HWW
Æ Hurricane Warning HUW
Æ Severe Thunderstorm Warning SVR
Æ Special Marine Warning SMW
Æ Tornado Warning TOR
Æ Tropical Storm Warning TRW
Æ Tsunami Warning TSW
Æ Volcano Warning VOW
Æ Winter Storm Warning WSW
Alert Gateway uses the CAP responseType element to populate this element. Code values:
‘‘Shelter’’—Take shelter in place.
‘‘Evacuate’’—Relocate.
‘‘Prepare’’—Make preparations.
‘‘Execute’’—Execute a pre-planned activity.
‘‘Monitor’’—Attend to information sources.
‘‘Assess’’—Evaluate the information in this message. (This value SHOULD NOT be used in
public warning applications.).
‘‘None’’—No action recommended.
Multiple instances MAY occur within a single block. This element is passed to
the mobile device.
Alert Gateway uses the CAP severity element to populate this element. Code Values sent to
the mobile device:
‘‘Extreme’’—Extraordinary threat to life or property.
‘‘Severe’’—Significant threat to life or property.
Alert Gateway uses the CAP urgency element to populate this element. Code Values sent to
the mobile device:
‘‘Immediate’’—Responsive action SHOULD be taken immediately.
‘‘Expected’’—Responsive action SHOULD be taken soon (within next hour).
Alert Gateway uses the CAP certainty element to populate this element. Code Values sent to
the mobile device:
‘‘Observed’’—Determined to have occurred or to be ongoing.
‘‘‘‘Likely’’—Likely (probability > 50%).
The expiry time of the information of the alert message for use by the CMSP Gateway. The
date and time is represented in UTC [dateTime] format. Maximum duration is 24 hours. Derived from the CAP expires element.
Optional element for logging purposes at the CMSP Gateway. The human-readable name of
the agency or authority issuing this alert. Alert Gateway uses the CAP senderName element
to populate this element.
Specifies the language of the text in the CMAC_text_alert_message, for use by the mobile device.
Code Values: ‘‘English’’, ‘‘Spanish’’, ‘‘French’’ (future Canada use only), ‘‘Other’’—for future
use.
Specified by the Alert Gateway and derived from the CAP language element.
PO 00000
Frm 00055
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
600
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
TABLE 10–3.—CMAC_ALERT_INFO SEGMENT—Continued
CMAC element
Mandatory/
optional/
conditional
CMAC_text_encoding ................
M ................
CMAC_text_alert_message_
length.
M ................
CMAC_text_alert_message ........
M ................
CMAC_web_link .........................
O ................
CMAC definition
Specifies the data encoding scheme of the text in the CMAC_text_alert_message, for use by
the mobile device.
Code Values: ‘‘UTF–8’’.
Specified by the Alert Gateway.
The length, in characters, of the text in the CMAC_text_alert_message. Note the number of octets in the CMAC_text_alert_message can be derived from this parameter and the CMAC_
text_encoding parameter. Specified by the Alert Gateway.
The text of the alert message for use by the mobile device. This field is defined by the CMAS
Text Profile and may contain up to 90 English characters using a 7-bit encoding scheme.
Other languages or data encoding schemes will change the number of characters supported.
Specified by the Alert Gateway, which may be derived or obtained via CAP elements.
Optional element for future use. The identifier of the hyperlink associating additional information with the alert message. This data must be in a domain accessible by the CMSP Gateway. Alert Gateway uses the CAP web element to populate this element.
10.4.2.3 CMAC_Area Segment
Multiple occurrences are permitted.
TABLE 10–4.—CMAC_AREA SEGMENT
CMAC element
Mandatory/
optional/
conditional
CMAC_area ...............................
M ................
CMAC_area_description ............
M ................
CMAC_polygon ..........................
O ................
CMAC_circle ..............................
O ................
CMAC_cmas_geocode ..............
M ................
CMSC_gnis ................................
O ................
10.4.2.4 CMAC_Resource Segment
Multiple occurrences are permitted. The
CMAC_Resource segment is not used for the
CMAC definition
(1) Multiple occurrences permitted, in which case the target area for the
block is the union of all the included blocks.
(2) MAY contain one or multiple instances of or , and shall
contain at least one instance of . If multiple , or elements are included, the area described by this is the
union of those represented by the included elements.
The text describing the affected area of the alert message for use by the CMSP for logging
purposes only. Alert Gateway uses the CAP areaDesc element to populate this element.
Optional element. The paired values of points defining a polygon that delineates the affected
area of the alert message. Alert Gateway uses the CAP polygon element to populate this
element.
Optional element. The paired values of a point and radius delineating the affected area of the
alert message. Alert Gateway uses the CAP circle element to populate this element.
The CMAS-defined geographic code delineating the affected area of the alert message. This is
an extension to the FIPS code (see Section 10.4.5). Alert Gateway uses the CAP geocode,
polygon, circle, and/or sender elements to derive this element.
Optional element. This value is the geographic code delineating the affected area of the alert
message using the U.S.G.S. Geographic Names Information System (GNIS) code. Derived
by the Alert Gateway.
Text Profile but may be applicable to future
streaming audio, streaming video, and
multimedia alerts.
TABLE 10–5.—CMAC_R RESOURCE SEGMENT
Mandatory/
optional/
conditional
CMAC_resource .........................
O ................
CMAC_resource_description .....
sroberts on PROD1PC70 with PROPOSALS
CMAC element
O ................
CMAC_mime_type .....................
O ................
CMAC_resource_size ................
O ................
CMAC_resource_uri ...................
O ................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC definition
(1) Refers to an additional file with supplemental information related to this
element; e.g., an image or audio file.
(2) Multiple occurrences MAY occur within a single block.
Optional element. The human-readable text describing the content and kind, such as ‘‘map’’ or
‘‘photo,’’ of the resource file. For use by the CMSP Gateway for logging purposes only. Alert
Gateway uses the CAP resourceDesc element to populate this element.
Optional element. The identifier of the MIME content type and sub-type describing the resource
file. Alert Gateway uses the CAP mimeType element to populate this element.
Optional element. The integer indicating the size of the resource file. Alert Gateway uses the
CAP size element to populate this element.
Optional element. The identifier of the hyperlink for the resource file. Alert Gateway uses the
CAP uri element to populate this element.
PO 00000
Frm 00056
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
601
TABLE 10–5.—CMAC_R RESOURCE SEGMENT—Continued
Mandatory/
optional/
conditional
CMAC_digest .............................
sroberts on PROD1PC70 with PROPOSALS
CMAC element
O ................
10.4.3 Example CMAC XML Schema
CMAC Alert Message
(version 1.0)
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC definition
Optional element. The code representing the digital digest (‘‘hash’’) computed from the resource file. Calculated using the Secure Hash Algorithm (SHA–1) per [FIPS 180–2]. Alert
Gateway uses the CAP digest element to populate this element.
PO 00000
Frm 00057
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
602
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
10.4.4 Element Mapping From B Reference
Point (CAP) to C Reference Point (CMAC) to
E Reference Point (CMAE) Elements
Note: elements listed in bold are
mandatory.
TABLE 10–6.—MAPPING REFERENCE POINT B ELEMENTS TO REFERENCE POINT C ELEMENTS
sroberts on PROD1PC70 with PROPOSALS
CAP element
CMAC element
N/A ..........................................................................................
N/A ..........................................................................................
N/A ..........................................................................................
identifier .................................................................................
references ...............................................................................
N/A ..........................................................................................
sender .....................................................................................
sent .........................................................................................
status ......................................................................................
msgType .................................................................................
source ......................................................................................
scope ......................................................................................
restriction .................................................................................
code .........................................................................................
note .........................................................................................
incidents ..................................................................................
N/A ..........................................................................................
category .................................................................................
event .......................................................................................
eventCode ...............................................................................
responseType ..........................................................................
severity ...................................................................................
urgency ..................................................................................
certainty .................................................................................
audience ..................................................................................
effective ...................................................................................
onset ........................................................................................
expires .....................................................................................
senderName ............................................................................
language ..................................................................................
N/A ..........................................................................................
N/A ..........................................................................................
parameter (when value = ‘‘CMAM text’’) ................................
headline ...................................................................................
description ...............................................................................
instruction ................................................................................
web ..........................................................................................
contact .....................................................................................
parameter (when value not = ‘‘CMAMtext’’) ...........................
areaDesc ................................................................................
polygon ....................................................................................
circle ........................................................................................
geocode ...................................................................................
geocode ...................................................................................
altitude .....................................................................................
ceiling ......................................................................................
resourceDesc .........................................................................
mimeType ................................................................................
size ..........................................................................................
uri ............................................................................................
derefUri ....................................................................................
digest .......................................................................................
N/A ..........................................................................................
CMAC_protocol_version .....................
N/A .........................................................
CMAC_sending_alert_gateway_id ......
CMAC_message_identifier ..................
CMAC_referenced_message_identifier
CMAC_special_handling ........................
CMAC_sender ......................................
CMAC_sent_date_time ........................
CMAC_status ........................................
CMAC_message_type ...........................
N/A .........................................................
N/A .........................................................
N/A .........................................................
N/A .........................................................
CMAC_n note ..........................................
N/A .........................................................
CMAC_original_cap_alert_uri .............
CMAC_category ...................................
N/A .........................................................
CMAC_event_code ................................
CMAC_response_type ...........................
CMAC_severity .....................................
CMAC_urgency ....................................
CMAC_certainty ...................................
N/A .........................................................
N/A .........................................................
N/A .........................................................
CMAC_expires_date_time ...................
CMAC_sender_name .............................
CMAC_text_language ..........................
CMAC_text_encoding ..........................
CMAC_text_alert_message_length .....
CMAC_text_alert_message .................
N/A .........................................................
N/A .........................................................
N/A .........................................................
CMAC_web_link .....................................
N/A .........................................................
N/A .........................................................
CMAC_area_description ......................
CMAC_polygon ......................................
CMAC_circle ..........................................
CMAC_cmas_geocode ........................
CMSC_gnis ............................................
N/A .........................................................
N/A .........................................................
CMAC_resource_description .................
CMAC_mime_type .................................
CMAC_resource_size ............................
CMAC_resource_uri ...............................
N/A .........................................................
CMAC_digest .........................................
N/A .........................................................
N/A ..........................................................................................
N/A ..........................................................................................
N/A .........................................................
N/A .........................................................
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
PO 00000
Frm 00058
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
CMAE element
N/A.
CMAE_protocol_version.
N/A.
CMAE_identifier.
N/A.
CMAE_alert_handling.
N/A.
N/A.
N/A.
CMAE_alert_type.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
CMAE_category.
N/A.
N/A.
CMAE_response_type.
CMAE_severity.
CMAE_urgency.
CMAE_certainty.
N/A.
N/A.
N/A.
CMAE_expires.
N/A.
CMAE_language.
CMAE_char_set.
CMAE_alert_text_length.
CMAE_alert_text.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
N/A.
CMAE_associated_multimedia_indicator.
CMAE_CMSP_defined_parameter.
CMAE_reserved.
03JAP2
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
10.4.5 Definition of CMAC_cmas_geocode
Element
The CMAC_cmas_geocode is five
characters where the first two characters or
digits identify the state or region and the last
three digits identify the specific counties,
regions, or equivalent entities. The CMSAAC
recommends that the CMAC_cmas_geocode
be assigned as follows:
1. The CMAC_cmas_geocode indication for
a specific county will be as defined in
Federal Information Processing Standard 6–
4 (FIPS 6–4), titled ‘‘Counties and Equivalent
Entities of the United States, Its Possessions,
and Associated Areas’’, dated 31 August
1990.
2. The CMAC_cmas_geocode indication for
an entire state will be the two digit FIPS State
Numeric Code as defined in Federal
Information Processing Standard 5–2 (FIPS
5–2), titled ‘‘Codes for the Identification of
the States, the District of Columbia and the
Outlying Areas of the United States, and
Associated Areas’’, dated 28 May 1987
followed by three zeroes (000).
3. The CMAC_cmas_geocode indication for
an entire United States including all states,
603
the District of Columbia, possessions, and
associated areas will be US000.
4. In the future, it is possible that alerts
may be targeted for regions of the country
(e.g., Gulf States). The more efficient and
error resistant solution would be to have
CMAC_cmas_geocode values for regional
areas such as FEMA regions or National
Weather Service (NWS) regions. The FEMA
regions would be assigned values in the
format of US0xx and the NWS regions would
be assigned values in the format of US1xx.
The following table defines the
CMAC_cmas_geocode value assignments.
TABLE 10–7.—CMAC_CMAS_GEOCODE ASSIGNMENTS
CMAC_cmas geocode
Definition
00000 ..............................................
00001 thru 99999 ............................
US000 .............................................
US001 .............................................
US002 .............................................
US003 .............................................
US004 .............................................
Not used.
For identification of states and counties.
Entire United States.
FEMA Region 1 (Maine, Vermont, New Hampshire, Rhode Island, Massachusetts, and Connecticut).
FEMA Region 2 (New York, New Jersey, Puerto Rico, and Virgin Islands).
FEMA Region 3 (Delaware, District of Columbia, Maryland, Pennsylvania, Virginia, and West Virginia).
FEMA Region 4 (Alabama, Florida, Georgia, North Carolina, South Carolina, Tennessee, Kentucky, and
Mississippi).
FEMA Region 5 (Illinois, Indiana, Michigan, Minnesota, Ohio, and Wisconsin).
FEMA Region 6 (Arkansas, Louisiana, New Mexico, Oklahoma, and Texas).
FEMA Region 7 (Iowa, Kansas, Missouri, and Nebraska).
FEMA Region 8 (Colorado, Montana, North Dakota, South Dakota, and Utah).
FEMA Region 9 (Arizona, California, Hawaii, Nevada, American Samoa, Guam, Commonwealth of the
Northern Mariana Islands, Republic of the Marshall Islands, and Federated States of Micronesia).
FEMA Region 10 (Alaska, Idaho, Oregon, and Washington).
Not Assigned.
National Weather Service (NWS) Central Region (Colorado, Illinois, Indiana, Iowa, Kansas, Kentucky,
Michigan, Minnesota, Missouri, and Nebraska).
National Weather Service (NWS) Eastern Region (Maine, Maryland, Massachusetts, New Jersey, New
York, North Carolina, Ohio, Pennsylvania, South Carolina, and Vermont).
National Weather Service (NWS) Southern Region (Alabama, Arkansas, Florida, Georgia, Louisiana, Mississippi, New Mexico, Oklahoma, Puerto Rico, Tennessee, and Texas).
National Weather Service (NWS) Western Region (Arizona, California, Idaho, Montana, Nevada, Oregon,
Utah, and Washington).
National Weather Service (NWS) Alaska Region (Alaska).
National Weather Service (NWS) Pacific Region (Hawaii, Guam, America Samoa).
Not Assigned.
US005
US006
US007
US008
US009
.............................................
.............................................
.............................................
.............................................
.............................................
US010 .............................................
US011 thru US100 ..........................
US101 .............................................
US102 .............................................
US103 .............................................
US104 .............................................
sroberts on PROD1PC70 with PROPOSALS
US105 .............................................
US106 .............................................
US107 thru US999 ..........................
10.4.6 Definition of CMAC Response Codes
The CMSAAC recommends the following
as the response codes that may be returned
from the CMSP Gateway to the Alert Gateway
in the CMAC_note element in response a
received CMAS message via the Reference
Point C interface:
CMAC_Error_100 Invalid Alert Gateway ID
CMAC_Error_101 Unsupported protocol
version
CMAC_Error_102 Segment XXX missing
CMAC_Error_103 Invalid message length
CMAC_Error_104 Mandatory element XXX
missing
CMAC_Error_105 Conditional element XXX
missing which is required based upon
value of element YYYY
CMAC_Error_106 Optional element XXX
not allowed
CMAC_Error_107 Unrecognized value in
element XXX
CMAC_Error_108 Value in element XXX is
out of acceptable range
CMAC_Error_109 Value XXX of element
YYY not supported
CMAC_Error_110 Invalid length of element
XXX
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
CMAC_Error_111 Expiration time greater
than allowed interval
CMAC_Error_112 Failure to convert text
message into alphabet encoding scheme
CMAC_Error_113 Text encoding not
compatible with specified text language
CMAC_Error_114 Special handling element
not consistent with message content
CMAC_Error_115 Polygon element contains
more than maximum number of
coordinates
CMAC_Error_200 Failure to retrieve
additional alert info from Alert Gateway
CMAC_Error_201 Message received after
expiration time
CMAC_Error_203 Message update failed
CMAC_Error_204 Message cancellation failed
CMAC_Error_300 Alert message failed due to
insufficient system storage
CMAC_Error_301 CMSP server error
CMAC_Error_302 Maximum number of
sessions reached (if C interface is session
based)
CMAC_Resp_400 CMAS test successful
CMAC_Resp_401 CMAS test failed due to
XXX
PO 00000
Frm 00059
Fmt 4701
Sfmt 4702
CMAC_Resp_500 Transient error on CMSP
Gateway—Discontinue transmission of
alerts
CMAC_Resp_501 Resume transmission of
alerts to CMSP Gateway
CMAC_Resp_502 Keep alive message
response
10.4.7 Example CMAS ‘‘C’’ Interface Alert
Messages
As an example of a CMAS Alert Message,
consider the following CAP alert
message from the National Weather
Service:
NOAA-NWS-ALERTS
Arizona 2007–08–01T18:22:17–04:00
cap:identifier>
w-nws.web
master@noaa.gov
2007–08–01T18:22:17–
04:00
Actual
Alert
Public
E:\FR\FM\03JAP2.SGM
03JAP2
604
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Current Watches, Warnings and
Advisories for Arizona Issued by the
National Weather Service
https://www.weather.gov/
alerts/az.html
Met
Flash Flood Warning
Expected
Severe
Likely
2007–08–
01T22:11:00
2007–08–01T23:15:00
Flash Flood Warning
cap:headline>
FLASH FLOOD
WARNING AZC005–012315—
BULLETIN—EAS ACTIVATION
REQUESTED FLASH FLOOD WARNING
NATIONAL WEATHER SERVICE
FLAGSTAFF AZ 311 PM MST WED
AUG 1 2007 THE NATIONAL
WEATHER SERVICE IN FLAGSTAFF
HAS ISSUED A * FLASH FLOOD
WARNING FOR... SOUTH CENTRAL
COCONINO COUNTY IN NORTH
CENTRAL ARIZONA... * UNTIL 415 PM
MST * AT 306 PM MST...NATIONAL
WEATHER SERVICE DOPPLER RADAR
INDICATED FLASH FLOODING FROM
A THUNDERSTORM OVER THE
WARNED AREA. * LOCATIONS IN THE
WARNING INCLUDE HIGHWAY 89
THROUGH OAK CREEK CANYON
BETWEEN SLIDE ROCK STATE PARK
AND MIDGELY BRIDGE. THE HEAVY
RAINS WILL LIKELY TRIGGER LIFETHREATENING ROCKSLIDES...
MUDSLIDES...AND DEBRIS FLOWS
NEAR THE BRINS FIRE BURN AREA IN
OAK CREEK CANYON...AS WELL AS
FLOODING OF CREEKS...ROADS...AND
NORMALLY DRY WASHES. DO NO
ATTEMPT TO DRIVE THROUGH THIS
AREA UNTIL THE THREAT HAS
DIMINISHED. LAT...LON 3488 11177
3489 11169 3499 11169 3498 11177 $$
DB
https://www.weather.gov/alerts/
AZ.html
#AZC005.FGZFFWFGZ.221100
cap:web>
Kaibab Plateau, Marble,
Glen Canyons, Grand Canyon Country,
Coconino Plateau, Northeast Plateaus,
Mesas Hwy, Little Colorado River Valley
in, Western Mogollon Rim, Eastern
Mogollon Rim, Oak Creek, Sycamore
Canyons, Northeast Plateaus, Mesas Sou
(Arizona)
004005
This Alert Gateway would construct a
CMAS ‘‘C’’ Interface message based on
this CAP alert as follows:
1.0
https://
cmas_alert_gateway.gov
1056
w-nws.webmaster
@noaa.gov
2003–06–17
T14:57:00–07:00
Actual
Alert
https://
cmas_alert_gateway.gov/CMAM1056
Met
Severe
Expected
Likely
2007–08–
01T23:15:00
English
ISO–6739–2
CMAC_text_encoding>
56
Severe Weather Warning
until 4:15pm MST
Kaibab Plateau,
Marble, Glen Canyons, Grand Canyon
Country, Coconino Plateau, Northeast
Plateaus, Mesas Hwy, Little Colorado
River Valley in, Western Mogollon Rim,
Eastern Mogollon Rim, Oak Creek,
Sycamore Canyons, Northeast Plateaus,
Mesas Sou (Arizona)
004005
This CMAM would be broadcast as:
Severe Weather Warning in this area until
4:15pm MST NWS
10.5
Reference Point E Protocols
The protocols that will be used for
Reference Point E are dependent upon the
capabilities of the delivery technology or
technologies that have been selected by the
CMSP.
The following is the CMA specific
information that must be delivered over
Reference Point ‘‘E’’ to support the CMAS
text profile; mapping of this information to
the delivery technology is beyond the scope
of the CMSAAC:
TABLE 10–8.—REFERENCE POINT E PROTOCOL ELEMENTS
Parameter
Function
CMAE_protocol_version ..................
CMAE_identifier ..............................
CMAE_alert_handling ......................
CMAE protocol version.
A number uniquely identifying this message.
Identifies special handling for the alert:
—Presidential Alert.
—Child Abduction Emergency (i.e., AMBER Alert)
Additional values are reserved for future use.
Alert message is new, update or cancel CMAS alert.
Language of the alert message in the CMAE_Alert_Text parameter.
Character set for the alert message in the CMAE_Alert_Text parameter (e.g., GSM 7-bit encoding, ISO
639–2, UCS–2, UTF–16).
sroberts on PROD1PC70 with PROPOSALS
CMAE_alert_type ............................
CMAE_language .............................
CMAE_char_set ..............................
11 Annex A—Anticipated Peak & Average
CMAS Traffic Volume
In 2006, there was a total of 9239 tornado
and flash flood warnings in the U.S. as
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
reported by the National Weather Service.
The following has a breakdown by state of
these warnings:
PO 00000
Frm 00060
Fmt 4701
Sfmt 4702
E:\FR\FM\03JAP2.SGM
03JAP2
It can be assumed that these warnings
account for approximately 50% of all
warnings issued in 2006. In addition, there
are approximately 1200 child abduction
emergency/Amber Alerts per year.
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
Given the above statistics and adding a
factor of uncertainty in, the anticipated
initial yearly CMAMs for a single language of
English which meet the criteria for CMAs is
assumed to be 25,000 alerts per year. This
PO 00000
Frm 00061
Fmt 4701
Sfmt 4702
605
number is expected to grow due to increased
usage and due to the potential support of
additional languages in the future.
On a monthly basis, the tornado and flash
flood data is as follows:
E:\FR\FM\03JAP2.SGM
03JAP2
EP03JA08.018
sroberts on PROD1PC70 with PROPOSALS
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
Using these actual alert statistics as a
percent of the total per month, and applying
to the 25,000 estimate number yields the
following estimate of alerts per month:
TABLE 11–3.—ESTIMATED CMA
VOLUME BY MONTH
CMA Estimate Per Month:
January .....................................
February ....................................
March ........................................
April ...........................................
May ...........................................
June ..........................................
July ............................................
August .......................................
September .................................
October .....................................
November ..................................
December ..................................
658
273
3158
3123
2695
3802
3001
2473
2535
1786
1050
446
Total .......................................
25000
Note there is significant uncertainty in
these estimates as one cannot predict
‘‘mother nature’’ or human activities. These
estimates should only serve as guidelines to
the anticipated message traffic in the CMAS.
sroberts on PROD1PC70 with PROPOSALS
12 Annex B—WARN Act Statutory
Requirements
12.1 WARN Act Requirements
1. Transmission of emergency alerts via
commercial mobile service is voluntary.
a. Commercial mobile service operators
may voluntarily elect to transmit emergency
alerts {Sec. 602(a)}.
2. A commercial mobile service operator
who elects to transmit emergency alerts agree
to do so in a manner consistent with the
technical standards, protocols, procedures,
and other technical requirements
implemented by the Commission.17
3. A commercial mobile service operator
who elects to transmit emergency alerts can
elect to transmit the emergency alert services
in whole or in part.18
17 WARN
Act, § 602(b)(2)(B)(ii).
Act, § 602(b)(1)(B). The Committee
interprets the definition of ‘‘in whole or in part’’ to
18 WARN
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
4. A commercial mobile service operator
who elects in whole or in part NOT to
transmit emergency alerts:
a. Must provide clear and conspicuous
notice at point-of-sale of any devices with
which its commercial mobile service is
included, that it will not transmit such alerts
via the service it provides for the device.19
b. Must provide notification of this
decision to its existing subscribers.20
c. Shall not by itself provide a basis for
liability against the provider (including its
officers, directors, employees, vendors, and
agents).21
5. Commercial mobile service licensee may
not impose a separate or additional charge for
such transmission or capability.22
6. Any commercial mobile service licensee
electing to transmit emergency alerts may
offer subscribers the capability of preventing
the subscriber’s device from receiving such
alerts, or classes of such alerts, other than an
alert issued by the President.23
7. CMSPs who elect to transmit emergency
alerts may transmit in languages in addition
to English to the extent practical and
feasible.24
8. Any CMSP (including its officers,
directors, employees, vendors, and agents)
that transmits emergency alerts and meets its
obligations under this title shall not be liable
to any subscriber to, or user of, such person’s
service or equipment for
a. Any act or omission related to or any
harm resulting from the transmission of, or
failure to transmit, an emergency alert.25
b. The release to a government agency or
entity, public safety, fire service, law
enforcement official, emergency medical
service, or emergency facility of subscriber
include the following: All or a subset of the mobile
operator’s service area and/or all or a subset of
current and future mobile devices supported by the
mobile operator network.
19 Id. § 602(b)(1)(B).
20 Id. § 602(b)(1)(C).
21 Id. § 602(e)(2).
22 Id. § 602(b)(2)(C).
23 Id. § 602.(b)(2)(E) & Sec. 603(c)(5).
24 Id. § 603(c)(4)}.
25 Id. § 6022(e)(1)(A)}.
PO 00000
Frm 00062
Fmt 4701
Sfmt 4702
information used in connection with
delivering such an alert.26
12.2 WARN Act Interpretations
12.2.1 CMSP Election
The WARN Act specifies the election
process for a CMSP that elects to transmit
CMAs as follows:
602(b)(2) ELECTION—
(A) IN GENERAL—Within 30 days after the
Commission issues its order under paragraph
(1), each licensee providing commercial
mobile service shall file an election with the
Commission with respect to whether or not
it intends to transmit emergency alerts.27
The above mentioned election process
must be complete in September, 2008 as
specified in the timelines in the WARN Act.
The CMAS requires new technology
development and deployments, including
development of mobile device functionality
for CMAS and new mobile devices. The
requirements for this new technology will
not be available until the completion of the
CMSAAC process and the completion of the
FCC Report and Order in April, 2008 as
specified by the WARN Act. Typical
development cycles for a development of this
magnitude require up to 12 months of
standardization work in the appropriate
standards bodies once the requirements are
finalized followed by 18–24 months
implementation and deployment before
availability of the service and supporting
mobile devices.
Thus, a CMSP that files an election with
the Commission in September 2008 with the
intent to transmit emergency alerts is making
a commitment to support the development
and deployment of technology for the
following:
—‘‘C’’ reference point
—CMSP Gateway
—CMSP Infrastructure
—Mobile Device with CMAS functionality
and support of the CMSP selected
technology
However, the technology, capabilities for
deployment, and mobile devices may not be
26 Id.
27 Id.
E:\FR\FM\03JAP2.SGM
§ 602(e)(1)(B).
§ 602(b)(2).
03JAP2
EP03JA08.019
606
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 / Proposed Rules
607
recommendation, due to the required
standardization and development cycles for
the technology and capabilities of the mobile
devices. Full deployments may not occur
until a much later timeframe via a phased
implementation.
The above potential deployment timeline
is based upon the assumptions that (1) the
CMSAAC recommendations contained
within this document are accepted without
any major technical changes and (2) the
government documentation and deliverables
are available at the milestone dates indicated
on the timeline. The industry will begin
standardization efforts at the completion of
the CMSAAC recommendations but any
major technical changes to the CMSAAC
recommendations will adversely affect the
above potential deployment timeline.
There are factors outside of the CMSP’s
direct control that will influence the
deployment and availability of CMA service.
These factors include manufacturer
development cycles for equipment in the
CMSP infrastructure, manufacturer
commitment to support the delivery
technology of choice by the CMSP, and
mobile device manufacturer development of
the required CMAS functionality on the
mobile devices. Typically, a CMSP will have
equipment from multiple manufacturers
deployed in the CMSP infrastructure. Multivendor environments require feature
availability and deployment alignment, and
require interoperability testing between the
different manufacturers equipment. Also, if a
CMSP chooses a particular technology to
transmit alerts (e.g., cell broadcast), if a
vendor with which a CMSP has a
relationship chooses not to develop the same
capability, then the CMSP may be forced into
not electing to transmit alerts (at least not ‘‘in
whole’’).
It is also assumed the requirements,
development, and deployments of the Alert
Gateway and Alert Aggregator align with the
CMSP developments to allow for testing
during the development process and prior to
CMAS deployments.
(47 U.S.C. 397(6))) to install necessary
equipment and technologies on, or as part of,
any broadcast television digital signal
transmitter to enable the distribution of
geographically targeted alerts by commercial
mobile service providers that have elected to
transmit emergency alerts under this
section.28
VerDate Aug<31>2005
20:42 Jan 02, 2008
Jkt 214001
12.3 Licensees and Permittees of
Noncommercial Educations Broadcasting
Stations or Public Television Stations
The WARN Act requires in section 602(c)
that:
Within 90 days after the date on which the
Commission adopts relevant technical
standards based on recommendations of the
Commercial Mobile Service Alert Advisory
Committee, established pursuant to section
603(a), the Commission shall complete a
proceeding to require licensees and
permittees of noncommercial educational
broadcast stations or public broadcast
stations (as those terms are defined in section
397(6) of the Communications Act of 1934
PO 00000
Frm 00063
Fmt 4701
Sfmt 4702
This Committee acknowledges the
potential relevance of the rulemaking
described in section 602(c) of the WARN Act
to this Committee’s recommendations.
Accordingly, the Committee recommends
that the equipment and technologies
described in Section 602(c) of the WARN Act
be deployed promptly and in a manner
consistent with the Committee’s
recommendations. The Committee further
recommends that the national organization
representing the licensees and permittees of
non-commercial broadcast stations work with
the FCC pursuant to Section 602(c) on the
necessary equipment.
[FR Doc. E7–24876 Filed 1–2–08; 8:45 am]
BILLING CODE 6712–01–P
28 Id.
E:\FR\FM\03JAP2.SGM
§ 602(c).
03JAP2
EP03JA08.020
sroberts on PROD1PC70 with PROPOSALS
available for initial deployment and
subscriber purchase potentially 12 months
plus 18–24 months (approximately 30–36
months) following the CMSAAC
Agencies
[Federal Register Volume 73, Number 2 (Thursday, January 3, 2008)]
[Proposed Rules]
[Pages 546-607]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: E7-24876]
[[Page 545]]
-----------------------------------------------------------------------
Part II
Federal Communications Commission
-----------------------------------------------------------------------
47 CFR Chapter I
Commercial Mobile Alert System; Proposed Rule
Federal Register / Vol. 73, No. 2 / Thursday, January 3, 2008 /
Proposed Rules
[[Page 546]]
-----------------------------------------------------------------------
FEDERAL COMMUNICATIONS COMMISSION
47 CFR Chapter I
[PSHSB Docket No. 07-287; FCC 07-214]
Commercial Mobile Alert System
AGENCY: Federal Communications Commission.
ACTION: Notice of Proposed Rulemaking.
-----------------------------------------------------------------------
SUMMARY: By this Notice of Proposed Rulemaking, the Federal
Communications Commission (Commission or FCC) initiates a comprehensive
rulemaking to establish a Commercial Mobile Alert System (CMAS). In
particular, the Commission seeks comment on the recommendations of the
Commercial Mobile Services Alert Advisory Committee (CMSAAC). These
recommendations are attached as Appendix A. The Commission convened the
CMSAAC in compliance with the Warning Alert and Response Network (WARN)
Act, which requires that the FCC adopt technical standards, protocols,
procedures, and other technical requirements for the CMAS based on the
recommendations of the CMSAAC. The purpose of this rulemaking is to
create a mechanism under which CMS providers may elect to transmit
emergency alerts to the public. The Commission has initiated this
proceeding to comply with the Warning Alert and Response Network (WARN)
Act and to satisfy the Commission's mandate to promote the safety of
life and property through the use of wire and radio communication.
DATES: Comments are due on or before February 4, 2008, and reply
comments are due on or before February 19, 2008. Written comments on
the Paperwork Reduction Act proposed information collection requirement
must be submitted by the public, Office of Management and Budget (OMB),
and other interested parties on or before March 3, 2008.
ADDRESSES: Send comments and reply comments to the Office of the
Secretary, Federal Communications Commission, 445 12th Street, SW.,
Room TW-A325, Washington, DC 20554. You may submit comments, identified
by PSHSB Docket No. 07-287, by any of the following methods:
Federal eRulemaking Portal: https://www.regulations.gov/.
Follow the instructions for submitting comments.
Federal Communications Commission's Web site: https://
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
https://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 E