Commercial Mobile Alert System

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Chapter I

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

Commercial Mobile Alert System

AGENCY:

Federal Communications Commission.

ACTION:

Notice of Proposed Rulemaking.

SUMMARY:

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

DATES:

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

ADDRESSES:

Send comments and reply comments to the Office of the Secretary, Federal Communications Commission, 445 12th Street, SW., Room TW-A325, Washington, DC 20554. You may submit comments, identified by PSHSB Docket No. 07-287, by any of the following methods:

• Federal eRulemaking Portal:

http://www.regulations.gov/.

Follow the instructions for submitting comments.

• Federal Communications Commission's Web site:

http://www.fcc.gov/cgb/ecfs/.

Follow the instructions for submitting comments.

• People with Disabilities: Contact the FCC to request reasonable accommodations (accessible format documents, sign language interpreters, CART, etc.) by e-mail;

FCC504@fcc.gov

or phone: 202-418-0530 or TTY: 202-418-0432.

In addition to filing with the Secretary, a copy of any comments on the Paperwork Reduction Act information collection requirement contained herein should be submitted to the Federal Communications Commission via e-mail to

PRA@fcc.gov

and to Nicholas A. Fraser, Office of Management and Budget, via e-mail to

Nicholas_A._Fraser@omb.eop.gov

or via fax at 202-395-5167.

FOR FURTHER INFORMATION CONTACT:

Lisa M. Fowlkes, Deputy Bureau Chief, PSHSB, at (202) 418-7450 or Jeffery Goldthorp, Chief, Communications Services Analysis Division, PSHSB at (202) 418-1096. For additional information concerning the Paperwork Reduction Act information collection requirement contained in this document, send an e-mail to

PRA@fcc.gov

or contact Jerry Cowden at (202) 418-0447.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Notice of Proposed Rulemaking (NPRM) in PSHSB Docket No. 07-287, FCC 07-214, adopted December 14, 2007, and released December 14, 2007. The complete text of this document is available for inspection and copying during normal business hours in the FCC Reference Information Center, Portals II, 445 12th Street, SW., Room CY-A257, Washington, DC 20554. This document may also be purchased from the Commission's duplicating contractor Best Copy and Printing, Inc., Portals II, 445 12th Street, SW., Room CY-B402, Washington, DC 20554, telephone (800) 378-3160 or (202) 488-5300, facsimile (202) 488-5563, or via e-mail at

fcc@bcpiweb.com

. It is also available on the Commission's Web site at

http://www.fcc.gov.

This document contains a proposed information collection requirement. The Commission, as part of its continuing effort to reduce paperwork burdens, invites the general public and the OMB to comment on the proposed information collection requirement contained in this document, as required by the Paperwork Reduction Act of 1995, Public Law 104-13. Public and agency comments are due March 3, 2008.

Comments should address: (a) Whether the proposed collection of information is necessary for the proper performance of the functions of the Commission, including whether the information shall have practical utility; (b) the accuracy of the Commission's burden estimates; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on the respondents, including the use of automated collection techniques or other forms of information technology. In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment on how it might “further reduce the information collection burden for small business concerns with fewer than 25 employees.”

OMB Control Number:

None.

Title:

Election Whether To Participate in the Commercial Mobile Alert System.

Form No.:

N/A.

Type of Review:

New Collection.

Respondents:

Businesses or other for-profit.

Number of Respondents:

1,253.

Time per Response:

6 minutes.

Frequency of Response:

One-time.

Obligation to Respond:

Mandatory.

Total Annual Burden:

125.3 hours.

Total Annual Costs:

$0.

Privacy Act Impact Assessment:

N/A.

Nature and Extent of Confidentiality:

Not applicable.

Needs and Uses:

Section 602(b)(2)(A) of the WARN Act requires each Commercial Mobile Service (CMS) provider to notify the Commission, within 30 days of the Commission's release of the order adopting CMAS technical requirements and protocols, whether it intends to participate in the CMAS. The information collected will be the CMS provider's contact information and its election, i.e., a “yes” or “no,” on whether it intends to provide commercial mobile service alerts. The Commission will use the information collected to meet its statutory requirement under the WARN Act to accept licensees' election filings and to establish an effective CMAS that will provide the public with effective mobile alerts in a manner that imposes minimal regulatory burdens on affected entities.

Synopsis of the Notice of Proposed Rulemaking

1.

Background.

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

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

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

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

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

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

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

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

Service (PCS) spectrum is divided into six frequency blocks designated A through F, and the Commission has held auctions for each block. The Commission has created a small business size standard for Blocks C and F as an entity that has average gross revenues of less than $40 million in the three previous calendar years. For Block F, an additional small business size standard for “very small business” was added and is defined as an entity that, together with its affiliates, has average gross revenues of not more than $15 million for the preceding three calendar years. These small business size standards, in the context of broadband PCS auctions, have been approved by the SBA. No small businesses within the SBA-approved small business size standards bid successfully for licenses in Blocks A and B. There were 90 winning bidders that qualified as small entities in the C Block auctions. A total of 93 “small” and “very small” business bidders won approximately 40 percent of the 1,479 licenses for Blocks D, E, and F. On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block licenses; there were 113 small business winning bidders. On January 26, 2001, the Commission completed the auction of 422 C and F PCS licenses in Auction 35. Of the 35 winning bidders in this auction, 29 qualified as “small” or “very small” businesses. Subsequent events concerning Auction 35, including judicial and agency determinations, resulted in a total of 163 C and F Block licenses being available for grant.

57.

Narrowband Personal Communications Service.

The Commission held an auction for Narrowband Personal Communications Service (PCS) licenses that commenced on July 25, 1994, and closed on July 29, 1994. A second commenced on October 26, 1994 and closed on November 8, 1994. For purposes of the first two Narrowband PCS auctions, “small businesses” were entities with average gross revenues for the prior three calendar years of $40 million or less. Through these auctions, the Commission awarded a total of forty-one licenses, 11 of which were obtained by four small businesses. To ensure meaningful participation by small business entities in future auctions, the Commission adopted a two-tiered small business size standard in the Narrowband PCS Second Report and Order. A “small business” is an entity that, together with affiliates and controlling interests, has average gross revenues for the three preceding years of not more than $40 million. A “very small business” is an entity that, together with affiliates and controlling interests, has average gross revenues for the three preceding years of not more than $15 million. The SBA has approved these small business size standards. A third auction commenced on October 3, 2001 and closed on October 16, 2001. Here, five bidders won 317 (MTA and nationwide) licenses. Three of these claimed status as a small or very small entity and won 311 licenses.

58.

Wireless Communications Services.

This service can be used for fixed, mobile, radiolocation, and digital audio broadcasting satellite uses in the 2305-2320 MHz and 2345-2360 MHz bands. The Commission defined “small business” for the wireless communications services (WCS) auction as an entity with average gross revenues of $40 million for each of the three preceding years, and a “very small business” as an entity with average gross revenues of $15 million for each of the three preceding years. The SBA has approved these definitions. The Commission auctioned geographic area licenses in the WCS service. In the auction, which commenced on April 15, 1997 and closed on April 25, 1997, there were seven bidders that won 31 licenses that qualified as very small business entities, and one bidder that won one license that qualified as a small business entity.

59.

700 MHz Guard Bands Licenses.

In the 700 MHz Guard Bands Order, the Commission adopted size standards for “small businesses” and “very small businesses” for purposes of determining their eligibility for special provisions such as bidding credits and installment payments. A small business in this service is an entity that, together with its affiliates and controlling principals, has average gross revenues not exceeding $40 million for the preceding three years. Additionally, a “very small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $15 million for the preceding three years. SBA approval of these definitions is not required. An auction of 52 Major Economic Area (MEA) licenses for each of two spectrum blocks commenced on September 6, 2000, and closed on September 21, 2000. Of the 104 licenses auctioned, 96 licenses were sold to nine bidders. Five of these bidders were small businesses that won a total of 26 licenses. A second auction of remaining 700 MHz Guard Bands licenses commenced on February 13, 2001, and closed on February 21, 2001. All eight of the licenses auctioned were sold to three bidders. One of these bidders was a small business that won a total of two licenses. Subsequently, in the 700 MHz Second Report and Order, the Commission reorganized the licenses pursuant to an agreement among most of the licensees, resulting in a spectral relocation of the first set of paired spectrum block licenses, and an elimination of the second set of paired spectrum block licenses (many of which were already vacant, reclaimed by the Commission from Nextel). A single licensee that did not participate in the agreement was grandfathered in the initial spectral location for its two licenses in the second set of paired spectrum blocks. Accordingly, at this time there are 54 licenses in the 700 MHz Guard Bands.

60.

700 MHz Band Commercial Licenses.

There is 80 megahertz of non-Guard Band spectrum in the 700 MHz Band that is designated for commercial use: 698-757, 758-763, 776-787, and 788-793 MHz Bands. With one exception, the Commission adopted criteria for defining two groups of small businesses for purposes of determining their eligibility for bidding credits at auction. These two categories are: (1) “small business,” which is defined as an entity that has attributed average annual gross revenues that do not exceed $15 million during the preceding three years; and (2) “very small business,” which is defined as an entity with attributed average annual gross revenues that do not exceed $40 million for the preceding three years. In Block C of the Lower 700 MHz Band (710-716 MHz and 740-746 MHz), which was licensed on the basis of 734 Cellular Market Areas, the Commission adopted a third criterion for determining eligibility for bidding credits: an “entrepreneur,” which is defined as an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $3 million for the preceding three years. The SBA has approved these small size standards.

61. An auction of 740 licenses for Blocks C (710-716 MHz and 740-746 MHz) and D (716-722 MHz) of the Lower 700 MHz Band commenced on August 27, 2002, and closed on September 18, 2002. Of the 740 licenses available for auction, 484 licenses were sold to 102 winning bidders. Seventy-two of the winning bidders claimed small business, very small business, or entrepreneur status and won a total of 329 licenses. A second auction commenced on May 28, 2003, and closed on June 13, 2003, and included 256 licenses: five EAG licenses and 251 CMA licenses. Seventeen winning bidders claimed small or very small business status and won 60 licenses,

and nine winning bidders claimed entrepreneur status and won 154 licenses.

62. The remaining 62 megahertz of commercial spectrum is currently scheduled for auction on January 24, 2008. As explained above, bidding credits for all of these licenses will be available to “small businesses” and “very small businesses.”

63.

Advanced Wireless Services.

In the AWS-1 Report and Order, the Commission adopted rules that affect applicants who wish to provide service in the 1710-1755 MHz and 2110-2155 MHz bands. The Commission did not know precisely the type of service that a licensee in these bands might seek to provide. Nonetheless, the Commission anticipated that the services that will be deployed in these bands may have capital requirements comparable to those in the broadband Personal Communications Service (PCS), and that the licensees in these bands will be presented with issues and costs similar to those presented to broadband PCS licensees. Further, at the time the broadband PCS service was established, it was similarly anticipated that it would facilitate the introduction of a new generation of service. Therefore, the AWS-1 Report and Order adopts the same small business size definition that the Commission adopted for the broadband PCS service and that the SBA approved. In particular, the AWS-1 Report and Order defines a “small business” as an entity with average annual gross revenues for the preceding three years not exceeding $40 million, and a “very small business” as an entity with average annual gross revenues for the preceding three years not exceeding $15 million. The AWS-1 Report and Order also provides small businesses with a bidding credit of 15 percent and very small businesses with a bidding credit of 25 percent.

64.

Broadband Radio Service and Educational Broadband Service.

Broadband Radio Service (“BRS”), formerly known as Multipoint Distribution Service (“MDS”), and Educational Broadband Service (“EBS”), formerly known as Instructional Television Fixed Service (“ITFS”), use frequencies at 2150-2162 and 2500-2690 MHz to transmit video programming and provide broadband services to residential subscribers. These services, collectively referred to as “wireless cable,” were originally designed for the delivery of multichannel video programming, similar to that of traditional cable systems, but over the past several years licensees have focused their operations instead on providing two-way high-speed Internet access services. We estimate that the number of wireless cable subscribers is approximately 100,000, as of March 2005. As described below, the SBA small business size standard for the broad census category of Cable and Other Program Distribution, which consists of such entities generating $13.5 million or less in annual receipts, appears applicable to MDS and ITFS. Other standards also apply, as described.

65. The Commission has defined small MDS (now BRS) entities in the context of Commission license auctions. In the 1996 MDS auction, the Commission defined a small business as an entity that had annual average gross revenues of less than $40 million in the previous three calendar years. This definition of a small entity in the context of MDS auctions has been approved by the SBA. In the MDS auction, 67 bidders won 493 licenses. Of the 67 auction winners, 61 claimed status as a small business. At this time, the Commission estimates that of the 61 small business MDS auction winners, 48 remain small business licensees. In addition to the 48 small businesses that hold BTA authorizations, there are approximately 392 incumbent MDS licensees that have gross revenues that are not more than $40 million and are thus considered small entities. MDS licensees and wireless cable operators that did not receive their licenses as a result of the MDS auction fall under the SBA small business size standard for Cable and Other Program Distribution. Information available to us indicates that there are approximately 850 of these licensees and operators that do not generate revenue in excess of $13.5 million annually. Therefore, we estimate that there are approximately 850 small entity MDS (or BRS) providers, as defined by the SBA and the Commission's auction rules.

66. Educational institutions are included in this analysis as small entities; however, the Commission has not created a specific small business size standard for ITFS (now EBS). We estimate that there are currently 2,032 EBS licensees, and all but 100 of the licenses are held by educational institutions. Thus, we estimate that at least 1,932 EBS licensees are small entities.

67.

Common Carrier Paging.

As noted, the SBA has developed a small business size standard for wireless firms within the broad economic census category of “Wireless Telecommunications Carriers (except Satellite).” Under this category, the SBA deems a business to be small if it has 1,500 or fewer employees. Since 2007, the SBA has recognized wireless firms within this new, broad, economic census category. Prior to that time, the SBA had developed a small business size standard for wireless firms within the now-superseded census categories of “Paging” and “Cellular and Other Wireless Telecommunications.” Under the present and prior categories, the SBA has deemed a wireless business to be small if it has 1,500 or fewer employees. Because Census Bureau data are not yet available for the new category, we will estimate small business prevalence using the prior categories and associated data. For the first category of Paging, data for 2002 show that there were 807 firms that operated for the entire year. Of this total, 804 firms had employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more. For the second category of Cellular and Other Wireless Telecommunications, data for 2002 show that there were 1,397 firms that operated for the entire year. Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 1,000 employees or more. Thus, using the prior categories and the available data, we estimate that the majority of wireless firms can be considered small. Thus, under this category, the majority of firms can be considered small.

68. In the Paging Third Report and Order, we developed a small business size standard for “small businesses” and “very small businesses” for purposes of determining their eligibility for special provisions such as bidding credits and installment payments. A “small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues not exceeding $15 million for the preceding three years. Additionally, a “very small business” is an entity that, together with its affiliates and controlling principals, has average gross revenues that are not more than $3 million for the preceding three years. The SBA has approved these small business size standards. An auction of Metropolitan Economic Area licenses commenced on February 24, 2000, and closed on March 2, 2000. Of the 985 licenses auctioned, 440 were sold. Fifty-seven companies claiming small business status won. Also, according to Commission data, 365 carriers reported that they were engaged in the provision of paging and messaging services. Of those, we estimate that 360 are small, under the SBA-approved small business size standard.

69.

Wireless Communications Service.

This service can be used for fixed, mobile, radiolocation, and digital audio

broadcasting satellite uses. The Commission established small business size standards for the wireless communications services (WCS) auction. A “small business” is an entity with average gross revenues of $40 million for each of the three preceding years, and a “very small business” is an entity with average gross revenues of $15 million for each of the three preceding years. The SBA has approved these small business size standards. The Commission auctioned geographic area licenses in the WCS service. In the auction, there were seven winning bidders that qualified as “very small business” entities, and one that qualified as a “small business” entity.

70.

Wireless Communications Equipment Manufacturers.

While these entities are merely indirectly affected by our action, we see are describing them to achieve a fuller record. The Census Bureau defines this category as follows: “This industry comprises establishments primarily engaged in manufacturing radio and television broadcast and wireless communications equipment. Examples of products made by these establishments are: transmitting and receiving antennas, cable television equipment, GPS equipment, pagers, cellular phones, mobile communications equipment, and radio and television studio and broadcasting equipment.” The SBA has developed a small business size standard for Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing, which is: all such firms having 750 or fewer employees. According to Census Bureau data for 2002, there were a total of 1,041 establishments in this category that operated for the entire year. Of this total, 1,010 had employment of under 500, and an additional 13 had employment of 500 to 999. Thus, under this size standard, the majority of firms can be considered small.

71.

Software Publishers.

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

72.

NCE and Public Broadcast Stations.

The Census Bureau defines this category as follows: “This industry comprises establishments primarily engaged in broadcasting images together with sound. These establishments operate television broadcasting studios and facilities for the programming and transmission of programs to the public.” The SBA has created a small business size standard for Television Broadcasting entities, which is: such firms having $13 million or less in annual receipts. According to Commission staff review of the BIA Publications, Inc., Master Access Television Analyzer Database as of May 16, 2003, about 814 of the 1,220 commercial television stations in the United States had revenues of $12 (twelve) million or less. We note, however, that in assessing whether a business concern qualifies as small under the above definition, business (control) affiliations must be included. Our estimate, therefore, likely overstates the number of small entities that might be affected by our action, because the revenue figure on which it is based does not include or aggregate revenues from affiliated companies.

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

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

Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements

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

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

76. The RFA requires an agency to describe any significant alternatives that it has considered in developing its approach, which may include the following four alternatives (among

others): “(1) the establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance and reporting requirements under the rule for such small entities; (3) the use of performance rather than design standards; and (4) an exemption from coverage of the rule, or any part thereof, for such small entities.”

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

Federal Rules That May Duplicate, Overlap, or Conflict With the Proposed Rules

78. None.

Ex Parte Rules

66. These matters shall be treated as a “permit-but-disclose” proceeding in accordance with the Commission's ex parte rules. Persons making oral ex parte presentations are reminded that memoranda summarizing the presentations must contain summaries of the substance of the presentations and not merely a listing of the subjects discussed. More than a one or two sentence description of the views and arguments presented is generally required. Other requirements pertaining to oral and written presentations are set forth in section 1.1206(b) of the Commission's rules.

Ordering Clauses

67. It is ordered, that pursuant to sections 1, 4(i) and (o), 201, 303(r), 403, and 706 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i) and (o), 201, 303(r), 403, and 606, as well as by sections 602(a),(b),(c), (f), 603, 604 and 606 of the WARN Act, this Notice of Proposed Rulemaking IS hereby ADOPTED.

68. It is further ordered that the Commission's Consumer and Government Affairs Bureau, Reference Information Center, SHALL SEND a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory Flexibility Analysis, to the Chief Council for Advocacy of the Small Business Administration.

69. It is further ordered that the Commission's Public Safety and Homeland Security Bureau, shall send a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory Flexibility Analysis, to the National Institute for Standards and Technology (NIST).

Federal Communications Commission.

Marlene H. Dortch,

Secretary.

Appendix A—Commercial Mobile Service Alert Advisory Committee Commercial Mobile Alert Service Architecture and Requirements

Date: 10/12/2007.

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

Table of Contents

1 Introduction and Executive Summary

1.1 Executive Summary

1.1.1 Reference Architecture (Section 2)

1.1.2 Deployment Scenarios (Section 3)

1.1.3 CMAS Alert Scenarios (Section 4)

1.1.4 General Recommendations and Conclusions (Section 5)

1.1.5 Service Profiles (Section 6)

1.1.6 Mobile Device Functionality for CMAS Alerts (Section 7)

1.1.7 Security for CMAS Alerts (Section 8)

1.1.8 CMAS Reliability & Performance (section 9)

1.1.9 Interface Protocols for CMAS Alerts (Section 10)

1.2 Definitions

1.3 Acronyms

2 Reference Architecture

2.1 Functional Reference Model Diagram

2.2 Government Administered Elements Definitions & Requirements

2.2.1 Reference Point A

2.2.2 Alert Aggregator

2.2.3 Reference Point B

2.2.4 Alert Gateway

2.2.4.1 General Alert Gateway System Requirements

2.2.4.2 CMSP Profile Support

2.3 CMSP Administered Elements Definitions & Requirements

2.3.1 Reference Point C

2.3.2 CMSP Gateway

2.3.3 CMSP Infrastructure

2.3.4 Reference Points D & E

2.3.5 Mobile Device

3 Deployment Scenarios

3.1 Scenarios for Single Technology Deployed

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

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

3.1.3 Scenario—CMAS in Subset of Single Technology Operator's Network on All Devices

3.1.4 Scenario—CMAS in Subset of Single Technology Operator's Network on Subset of Devices

3.2 Scenarios for Multiple Technologies Deployed

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

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

3.2.3 Scenario—CMAS in Subset of Multiple Technology Operator Network on Subset of Devices

3.3 Scenario for Operator Does Not Elect to Transmit CMAS Alerts

3.4 Subscriber Notification Recommendations

3.4.1 Notification Procedures

3.4.2 Notification Text Recommendations

4 CMAS Alert Scenarios

4.1 Nominal CMAS Alert Scenarios

4.1.1 Scenario for Nominal Text CMAS Alert

4.1.1.1 Pre-Conditions

4.1.1.2 Normal Flow

4.1.2 Scenario for Nominal Streaming Audio or Streaming Video CMAS Alert

4.1.3 Scenario for Nominal Downloaded Multimedia CMAS Alert

4.2 CMAS Alert Cancellation Scenario

4.2.1 Pre-Conditions

4.2.2 Normal Flow

4.3 CMAS Alert Update Scenarios

4.3.1 Scenario for Update of Text CMAS Alert

4.3.1.1 Pre-Conditions

4.3.1.2 Normal Flow

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

4.3.3 Scenario for Update of Downloaded Multimedia CMAS Alert

4.4 CMAS Alert Expiration Scenario

4.4.1 Pre-Conditions

4.4.2 Normal Flow

4.5 Duplicate CMAS Alerts Scenarios

4.5.1 Scenario for Duplicate CMAS Alerts on Same Broadcast Technology

4.5.1.1 Pre-Conditions

4.5.1.2 Normal Flow

4.5.2 Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies

4.5.2.1 Pre-Conditions

4.5.2.2 Normal Flow

4.6 Multiple Different Active CMAS Alerts Scenario

4.6.1 Pre-Conditions

4.6.2 Normal Flow

5 General Requirements & Conclusions

5.1 Scope & Definition of CMAS Alerts

5.2 General CMAS Requirements & Conclusions

5.3 Recommendations for Alert Initiation & Alert Initiators

5.3.1 CMAM Elements

5.3.2 Generating CMAM From CAP Fields

5.3.2.1 Generating CMAM From Free Form Text

5.3.3 Presidential Message and AMBER Alert

5.3.4 Recommended Message Initiator Training

5.4 Recommendations for Geo-Targeting of CMAS Alerts

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

5.5.1 General Requirements

5.5.2 User Needs Requirements

5.5.2.1 Alert/Attention Signal

5.5.2.2 Message Content

5.5.2.3 Output Mode/Display

5.5.2.4 Behavior on Receipt of a Message

5.5.2.5 CMAS-Related Print and Online Materials

5.5.3 Subscriber CMA Opt-Out Recommendations

5.6 Recommendations for CMAM Transmissions

5.7 Multi-Language CMAS Alerts Recommendations

5.8 CMAS Reception Control on Mobile Devices

5.9 Roaming

6 Service Profiles

6.1 Conclusions on Text, Audio, Video & Multimedia Resources

6.2 Text Profile

6.3 Streaming Audio Profile (future capability)

6.4 Streaming Video Profile (future capability)

6.5 Downloaded Multimedia Profile (future capability)

7 Mobile Device Functionality for CMAS Alerts

7.1 General Requirements on Mobile Device Functionality

7.2 Mobile Device Audio Attention Signal & Vibration Cadence Recommendations

7.3 CMAS Functionality on Mobile Device

7.4 Impact to Mobile Device Battery Life

8 Security for CMAS Alerts

8.1 Alert Interface & Aggregator Trust Model

8.1.1 Trust Model Definitions

8.1.2 Trust Model Requirements

8.2 Alert Gateway Security Requirements

8.3 Reference Point C Security

8.4 Reference Points D & E Security

9 CMAS Reliability & Performance

9.1 Alert Gateway Performance Requirements

9.2 Alert Delivery Latency

9.3 CMAS End-to-End Reliability

9.4 Message Logging

9.4.1 Alert Gateway Logging

9.5 CMAS Testing

9.5.1 General CMAS Testing Recommendations

9.5.2 Alert Gateway Testing

10 Interface Protocols for CMAS Alerts

10.1 Reference Point A Protocol

10.2 Reference Point B Protocol

10.3 Alert Gateway Interfaces & Mapping Requirements

10.3.1 Alert Gateway Interface Requirements

10.3.2 Alert Gateway Interface Mapping Requirements

10.4 Reference Point C Protocol

10.4.1 Structure of the CMA “C” Reference Point Protocol

10.4.2 CMAC Data Dictionary

10.4.2.1 CMAC_Alert_Attributes Segment

10.4.2.2 CMAC_Alert_Info Segment

10.4.2.3 CMAC_Area Segment:

10.4.2.4 CMAC_Resource Segment:

10.4.3 Example CMAC XML Schema

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

10.4.5 Definition of CMAC_cmas_geocode Element

10.4.6 Definition of CMAC Response Codes

10.4.7 Example CMAS “C” Interface Alert Messages

10.5 Reference Point E Protocols

11 Annex A—Anticipated Peak & Average CMAS Traffic Volume

12 Annex B—WARN Act Statutory Requirements

12.1 WARN Act Requirements

12.2 WARN Act Interpretations

12.2.1 CMSP Election

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

List of Figures

Figure 2-1 CMAS Functional Reference Model

Figure 3-1 CMAS in Entire Single Technology Network on All Devices

Figure 3-2 CMAS in Entire Network on Sub-set of Devices

Figure 3-3 CMAS in Subset of Single Technology Operator's Network on All Devices

Figure 3-4 CMAS in Subset of Single Technology Operator's Network on Subset of Devices

Figure 3-5 CMAS in Entire Multiple Technology Operator Network on All Devices

Figure 3-6 CMAS in Entire Multiple Technology Operator Network on Subset of Devices

Figure 3-7 CMAS in Subset of Multiple Technology Operator Network on Subset of Devices

Figure 3-8 Operator Does Not Elect to Transmit CMAS Alerts

Figure 4-1 Flow for Scenario for Nominal Text CMAS Alert

Figure 4-2 Flow for CMAS Alert Cancellation Scenario

Figure 4-3 Flow for Scenario for Update of Text CMAS Alert

Figure 4-4 Flow for CMAS Alert Expiration Scenario

Figure 4-5 Flow for Scenario for Duplicate CMAS Alerts on Same Broadcast Technology

Figure 4-6 Flow for Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies

Figure 4-7 Flow for Scenario for Multiple Different Active CMAS Alerts Scenario

Figure 10-1 Relationship of CAP Elements to Reference Point C Elements

Figure 10-2 CMAC Message Structure

Figure 12-1 Potential Deployment Timeline

List of Tables

Table 2-1 CMSP Profile on Alert Gateway

Table 5-1 CAP Value Field Mapping to Text

Table 6-1 Text Profile

Table 6-2 Streaming Audio Profile

Table 6-3 Video Profile

Table 6-4 Downloaded Multimedia Profile

Table 10-1 Parameter Mapping from “B” Interface CAP Message in to “C” Interface CMAC message

Table 10-2 CMAC_Alert_Attributes Segment

Table 10-3 CMAC_Alert_Info Segment

Table 10-4 CMAC_Area Segment

Table 10-5 CMAC_Resource Segment

Table 10-6 Mapping Reference Point B Elements to Reference Point C Elements

Table 10-7 CMAC_cmas_geocode Assignments

Table 10-8 Reference Point E Protocol Elements

Table 11-1 Table of Total 2006 Tornado & Flash Flood Warnings by State

Table 11-2 Table of 2006 Tornado & Flash Flood Warnings by State by Month

Table 11-3 Estimated CMA Volume by Month

1 Introduction and Executive Summary

1.1 Executive Summary

On October 13, 2006, the President signed the Security and Accountability For Every Port (SAFE Port) Act

1

into law. Title VI of the SAFE Port Act, the Warning, Alert and Response Network (WARN) Act,

2

establishes a process for Commercial Mobile Service Providers (CMSPs) to voluntarily elect to transmit emergency alerts. Section 603(c) of the WARN Act required that the Federal Communications Commission (Commission) establish the Commercial Mobile Service Alert Advisory Committee (CMSAAC) to develop and recommend technical standards and protocols for the voluntary transmission of emergency alerts by CMSPs within one year from the date of enactment of the WARN Act. (i.e., by October 12, 2007).

3

This document presents the result of the CMSAAC's efforts to satisfy the obligations set forth in the WARN Act.

1

Security and Accountability For Every Port Act of 2006 (SAFE Port Act), Pub. L. 109-347.

2

Safe Port Act, Title VI-Commercial Mobile Service Alerts.

3

WARN Act, § 603(c).

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

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

(1) For protocols, technical capabilities, and technical procedures through which electing commercial mobile service providers receive, verify, and transmit alerts to subscribers (Sections 2, 4, 6, 8, 10);

(2) For the establishment of technical standards for priority transmission of alerts by electing commercial mobile service providers to subscribers (Sections 2, 9);

(3) For relevant technical standards for devices and equipment and technologies used by electing commercial mobile service providers to transmit emergency alerts to subscribers (Sections 7, 9);

(4) For the technical capability to transmit emergency alerts by electing commercial mobile service providers to subscribers in languages in addition to English, to the extent practicable and feasible (Section 5);

(5) Under which electing commercial mobile service providers may offer subscribers the capability of preventing the

subscriber's device from receiving emergency alerts, or classes of such alerts, (other than an alert issued by the President), consistent with Section 602(b)(2)(E) of the WARN Act (Section 5);

(6) For a process under which commercial mobile service providers can elect to transmit emergency alerts if

(a) Not all of the devices or equipment used by such provider are capable of receiving such alerts (Section 3); or

(b) The provider cannot offer such alerts throughout the entirety of its service area (Section 3); and

(7) As otherwise necessary to enable electing commercial mobile service providers to transmit emergency alerts to subscribers.

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

1.1.1 Reference Architecture (Section 2)

This section recommends a functional reference model for the distribution of alerts to Commercial Mobile Service Providers (CMSPs) (Section 2.1). Under this reference model, a Federal government entity, the “Alert Aggregator,” would receive, aggregate, and authenticate alerts originated by authorized alert initiators using the Common Alerting Protocol (CAP). The government entity would also act as an “Alert Gateway” (Section 2.2) to formulate a 90 character alert based on key fields in the CAP alert sent by the alert initiator

4

. Based on CMSP profiles maintained in the Alert Gateway, the Alert Gateway would then deliver the alert over a secure interface (see Section 2.3.1) to another gateway maintained by the appropriate CMSP “CMSP Gateway.” (Section 2.3.2)

4

Provisions have also been made for authorized alert originators to formulate and distribute alerts via the Alert Gateway in free text. See e.g., section 5.3.2, supra.

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

Upon receipt of an alert from the CMSP Gateway, the CMSP Infrastructure distributes the received CMAS alert message to the determined set of cell sites/paging transceivers and authenticates interactions with the Mobile Device (Section 2.3.3). Ultimately, the alert is received on a customer's Mobile Device. The major functions of the Mobile Device are to authenticate interactions with the CMSP Infrastructure, to monitor for CMAS alerts, to maintain customer options (such as the subscriber's opt-out selections and subscriber's preferred language, if applicable), and to activate the associated visual, audio, and mechanical (e.g., vibration) indicators that the subscriber has indicated as options when an alert is received on the Mobile Device. (Section 2.3.5.)

1.1.2 Deployment Scenarios (Section 3)

This section notes that the WARN Act specifies that a CMSP who elects to transmit emergency alerts can elect to transmit the CMAS alerts “in whole or in part.”

5

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

5

WARN Act, § 602(c).

1.1.3 CMAS Alert Scenarios (Section 4)

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

1.1.4 General Recommendations and Conclusions (Section 5)

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

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

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

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

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

1.1.5 Service Profiles (Section 6)

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

1.1.6 Mobile Device Functionality for CMAS Alerts (Section 7)

This section describes the impact to the mobile devices, i.e., the handsets, for the support of CMAS alerts. The section includes the recommendation that if the end user has both muted the mobile device audio and alarms and/or has deselected or turned off the vibration capabilities of the mobile device, neither the CMAS audio attention signal nor the special emergency alert vibration cadence will be activated upon receipt of a CMAS alert. Further, the section recommends that, in order to minimize the

possibility of network congestion and false alerts, mobile devices should not support any user interface capabilities to forward received CMAS alerts, to reply to received CMAS alerts, or to copy and paste CMAS alert contents. The section also notes that the monitoring for CMAS alerts could have a significant impact on handset battery life, but that with modifications to network infrastructure, mobile devices and/or standards, the reduction of battery life can be less than 10% of today's capability for monitoring.

1.1.7 Security for CMAS Alerts (Section 8)

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

1.1.8 CMAS Reliability & Performance (Section 9)

Recommendations in this section include Alert Gateway performance requirements such as the capability to monitor system utilization for capacity planning purposes, and to temporarily disable and buffer CMAS alert traffic in the event of an overload. The CMSAAC acknowledges the importance of assessing any latency in alert delivery, but notes that it will be difficult to predict system performance in this area prior to deployment. The CMSAAC suggests that factors relevant to potential latency include; mobile device battery life impact, call processing impact; capabilities of the delivery technology; message queues; number of languages; number of targeted cell sites/paging transceivers for the alert area; and any geo-targeting processing. Similarly, although the CMSAAC recommends that the CMAS end-to-end reliability technology meet telecom standards for highly reliable systems, the over-all reliability of CMAS is unpredictable because RF transmissions can be subject to noise and other interference or environmental factors; the capabilities of the cellular environment are not predictable especially in a disaster environment; the subscriber may be in a location that does not have any RF signal; and the subscriber's mobile device may not have any remaining power. In order to assure the reliability and performance of this new system, the CMSAAC recommends procedures for logging CMAS alerts at the Alert Gateway and for testing the system at the Alert Gateway and on an end-to-end basis.

1.1.9 Interface Protocols for CMAS Alerts (Section 10)

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

1.2 Definitions

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

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

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

Commercial Mobile Service Provider (CMSP)—Per the WARN Act Section 602(b)(1)(A), a CMSP is a licensee providing commercial mobile service as defined in section 332(d)(1) of the Communications Act of 1934 (47 U.S.C. 332(d)(1)), where the term “commercial mobile service” means any mobile service that is provided for profit and makes interconnected service available.

6

6

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

1.3 Acronyms

AMBER America's Missing: Broadcast Emergency Response

CAP Common Alerting Protocol as defined in CAP version 1.1 specification

CDMA Code Division Multiple Access

CMA Commercial Mobile Alert

CMAM Commercial Mobile Alert Message

CMAS Commercial Mobile Alert Service

CMSAAC Commercial Mobile Service Alert Advisory Committee

CMSP Commercial Mobile Service Provider

CTIA Cellular Telecommunications Industry Association

EOC Emergency Operations Center

FIPS Federal Information Processing Standards

GNIS Geographic Names Information System

GSM Global System for Mobile communications

NOAA National Oceanic and Atmospheric Administration

MVNO Mobile Virtual Network Operator

NIST National Institute of Standards and Technology

NWS National Weather Service

SAME Specific Area Message Encoding

SMS Short Message Service

UMTS Universal Mobile Telecommunications System

VPN Virtual Private Network

WARN Warning, Alert, and Response Network

XML Extensible Markup Language

2 Reference Architecture

EP03JA08.000

2.2 Government Administered Elements Definitions & Requirements

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

2.2.1 Reference Point A

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

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

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

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

2.2.2 Alert Aggregator

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

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

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

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

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

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

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

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

2.2.3 Reference Point B

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

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

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

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

2.2.4 Alert Gateway

2.2.4.1 General Alert Gateway System Requirements

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

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

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

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

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

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

6. Deployment to achieve geographic separation from the CMSP Gateway.

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

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

2.2.4.2 CMSP Profile Support

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

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

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

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

Table 2-1.—CMSP Profile on Alert Gateway

Profile parameter

Parameter election

Description

CMSP Name

Unique identification of CMSP.

CMSP Gateway Address

IP address or Domain Name

Alternate IP address

Optional and subject to implementation.

Geo-Location Filtering

<yes/no>

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

If “no”, all CMAM will be sent to the CMSP Gateway.

If yes, list of states

CMAC Geocode for state

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

2.3 CMSP Administered Elements Definitions & Requirements

2.3.1 Reference Point C

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

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

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

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

2.3.2 CMSP Gateway

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

1. Authentication of interactions with the Alert Gateway.

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

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

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

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

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

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

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

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

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

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

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

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

14. The CMSP Gateway application will support CMAM:

a. Authentication.

b. Message integrity.

c. Availability (i.e. keep alive messages).

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

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

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

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

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

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

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

2.3.3 CMSP Infrastructure

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

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

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

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

2.3.4 Reference Points D & E

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

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

2.3.5 Mobile Device

Mobile device functionality is generally dependent on delivery technology, the capabilities of the delivery technology, and mobile vendor/CMSP specific policy and requirements. CMAS should allow for mobile device vendor flexibility in the design of CMA user interactions, and allow for innovation by the mobile device vendors and CMSPs, especially as mobile device

technology advances. The following are general guidelines recommended by the CMSAAC for the functions to be performed by the Mobile Device:

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

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

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

4. Maintain configuration of CMAS alert options including the following:

a. Subscriber's choice of CMAS alert opt-out selections.

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

c. Default language is English if CMAS alert is not being transmitted in subscriber's preferred language.

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

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

a. Presidential level CMAS alerts are always presented.

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

7. Detection and suppression of presentation of duplicate CMAS alerts.

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

3 Deployment Scenarios

The WARN Act specifies that a commercial mobile service operator who elects to transmit emergency alerts can elect to transmit the CMAS alerts in whole or in part.

7

The CMSAAC recommends that the definition of “in whole or in part” include the following:

7

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

• All or a subset of the CMSP's service area.

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

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

1. Potential date of initial deployment.

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

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

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

Note:

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

3.1 Scenarios for Single Technology Deployed

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

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

EP03JA08.001

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

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

EP03JA08.002

3.1.3 Scenario—CMAS in Subset of Single Technology Operator's Network on All Devices

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

EP03JA08.003

3.1.4 Scenario—CMAS in Subset of Single Technology Operator's Network on Subset of Devices

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

EP03JA08.004

3.2 Scenarios for Multiple Technologies Deployed

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

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

EP03JA08.005

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

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

EP03JA08.006

3.2.3 Scenario—CMAS in Subset of Multiple Technology Operator Network on Subset of Devices

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

EP03JA08.007

3.3 Scenario for Operator Does Not Elect to Transmit CMAS Alerts

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

EP03JA08.008

3.4 Subscriber Notification Recommendations

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

3.4.1 Notification Procedures

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

3.4.2 Notification Text Recommendations

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

I. NOTICE BY CARRIER WHO INTENDS TO TRANSMIT EMERGENCY ALERTS “IN PART.”

NOTICE REGARDING TRANSMISSION OF WIRELESS EMERGENCY ALERTS (Commercial Mobile Alert Service)

[[WIRELESS PROVIDER]] has chosen to offer wireless emergency alerts within portions of its service area, as defined by the terms and conditions of its service agreement, on wireless emergency alert capable devices. There is no additional charge for these wireless emergency alerts.

Wireless emergency alerts may not be available on all devices or in the entire service area, or if a subscriber is outside of the [WIRELESS PROVIDER's] service area. For details on the availability of this service and wireless emergency alert capable devices, please ask a sales representative, or go to [[INSERT WEB SITE URL]].

Notice required by FCC Rule XXXX (Commercial Mobile Alert Service).

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

NOTICE TO NEW AND EXISTING SUBSCRIBERS REGARDING TRANSMISSION OF WIRELESS EMERGENCY ALERTS (Commercial Mobile Alert Service)

[[WIRELESS PROVIDER]] presently does not transmit wireless emergency alerts.

Notice required by FCC Rule XXXX (Commercial Mobile Alert Service).

4 CMAS Alert Scenarios

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

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

• CMAS alert cancellation scenario.

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

• CMAS alert expiration scenario.

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

• Multiple different active CMAS alert scenarios.

• Multiple different CMAS alerts.

4.1 Nominal CMAS Alert Scenarios

4.1.1 Scenario for Nominal Text CMAS Alert

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

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

4.1.1.1 Pre-Conditions

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

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

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

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

5. There is no active CMAM on mobile device.

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

4.1.1.2  Normal Flow

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

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

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

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

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

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

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

5. The CMSP validates the received CMAM.

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

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

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

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

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

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

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

a. The CMAM is broadcast via the CMSP selected technology.

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

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

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

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

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

BILLING CODE 6712-01-P

EP03JA08.009

BILLING CODE 6712-01-C

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

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

4.2 CMAS Alert Cancellation Scenario

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

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

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

4.2.1 Pre-Conditions

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

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

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

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

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

4.2.2 Normal Flow

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

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

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

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

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

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

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

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

5. The CMSP validates the received CMAM cancellation.

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

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

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

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

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

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

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

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

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

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

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

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

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

EP03JA08.010

4.3 CMAS Alert Update Scenarios

4.3.1 Scenario for Update of Text CMAS Alert

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

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

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

4.3.1.1 Pre-Conditions

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

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

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

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

5. A CMAM may be active on mobile device.

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

4.3.1.2 Normal Flow

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

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

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

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

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

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

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

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

5. The CMSP validates the received updated CMAM.

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

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

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

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

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

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

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

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

a. The updated CMAM is broadcast via the CMSP selected technology.

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

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

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

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

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

EP03JA08.011

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

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

4.3.3 Scenario for Update of

Downloaded Multimedia CMAS Alert

Downloaded multimedia CMAS alerts are a future capability.

4.4 CMAS Alert Expiration Scenario

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

4.4.1 Pre-Conditions

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

4.4.2 Normal Flow

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

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

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

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

EP03JA08.012

4.5 Duplicate CMAS Alerts Scenarios

4.5.1 Scenario for Duplicate CMAS Alerts on Same Broadcast Technology

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

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

4.5.1.1 Pre-Conditions

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

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

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

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

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

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

4.5.1.2 Normal Flow

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

1. The CMSP network retransmits a previously broadcast CMAM.

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

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

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

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

EP03JA08.013

4.5.2 Scenario for Duplicate CMAS Alerts on Different Broadcast Technologies

An event has occurred and the appropriate government entities have decided to issue a text based CMA to warn the CMSP subscribers within the indicated alerting area. The CMSP network supports more than one broadcast technology in the indicated alerting area and the CMSP elects to broadcast the CMA on more than one technology in the indicated alerting area. Support of multiple broadcast technologies by the CMSP network may be result of the deployment and implementation of newer broadcast technologies. This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting subscribers into the service area of the CMSP network which will be broadcasting the CMA.

4.5.2.1 Pre-Conditions

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

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

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

4. No previous CMAM is being broadcast by the CMSP.

5. There is no active CMAM on mobile device.

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

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

4.5.2.2 Normal Flow

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

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

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

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

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

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

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

5. The CMSP validates the received CMAM.

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

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

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

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

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

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

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

a. The CMAM is broadcast via the first CMSP selected technology.

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

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

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

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

a. The CMAM is broadcast via the second CMSP selected technology.

11. The CMAM is received from both the first and second broadcast technologies.

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

a. If the CMAM is not a Presidential alert and if the end user opt-out selections for CMAS alerts indicate that this type of CMAS

alert is not to be presented, the CMAM is discarded or ignored. End of scenario.

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

BILLING CODE 6712-01-P

EP03JA08.014

BILLING CODE 6712-01-C

4.6 Multiple Different Active CMAS Alerts Scenario

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

The CMSP processes CMAM received from the Alert Gateway on a first come first served basis. There is no prioritization of processing or delivery of CMAM within the CMSP network. This scenario applies to both the CMSP subscribers and to subscribers who are roaming as visiting subscribers into the service area of the CMSP network which will be broadcasting the CMA.

4.6.1 Pre-Conditions

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

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

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

4. No previous CMAM is being broadcast by the CMSP.

5. There is no CMAM on mobile device.

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

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

4.6.2 Normal Flow

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

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

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

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

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

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

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

5. The CMSP validates the 1st received CMAM.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14. The CMSP validates the 2nd received CMAM.

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

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

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

This text is long and has been trimmed here. Open the source document for the complete record.