Commercial Mobile Alert System Status Update

1. Commercial Mobile Alert SystemStatus Update Prepared for: 7th SDO Emergency Services Coordination Workshop May 2010 (ESW7) College Park, MD, USA Presented by: Peter Musgrove ATIS WTSC G3GSN Chair peter.musgrove@att.com Brian K. Daly (via phone conference) Director, Core & Gov’t/Regulatory Standards, AT&T brian.k.daly@att.com

2. Background • “Warning, Alert, and Response Network Act” • WARN Act • U.S. Congress Passed the WARN Act as Part of SAFE Port Act on September 20, 2006 • Signed by U.S. President George W. Bush on Friday October 13th, 2006 • Required the FCC to Establish the Commercial Mobile Service Alert Advisory Committee (CMSAAC) within 60 days of enactment • Tasked for development of system-critical recommendations

3. WARN Act Milestones These Milestones are Complete! Mandated Operator Election Date

4. CMAS Update • Since the completion of the CMSAAC and release of the FCC Report & Orders for CMAS, the industry (joint ATIS & TIA) has been engaged in a joint effort with government on developing a set of standards to support the Commercial Mobile Alert System • This 28+ month effort to date has resulted in a series of standards based on Cell Broadcast technology for realizing the FCC Rules & the CMSAAC Recommendations. • Cell Broadcast is the technology chosen by operators, handset vendors, and infrastructure vendors to realize CMAS after careful & unbiased analysis of all possible technologies • Cell Broadcast is a global standard that will support the Public Warning System defined in international standards • These standards meet and even exceed the FCC rules, and are jointly supported by industry (operators, handset vendors, infrastructure vendors) as well as government (DHS, FEMA)

5. What is the Commercial Mobile Alert System (CMAS)? CMAS Alerts The User to React Immediately then Obtain Further Information that is Readily Available • CMAS is a “bell ringer” intended to get the subscribers attention to an imminent threat to life or property, and to communicate immediate action necessary to protect oneself • Tornado Warning in this area until 7:00pm Take Shelter Now NWS • Consistent User Experience Across Devices & Operators • Common Mobile Device Behavior includes: • Reception Control (“subscriber opt-out”) • Alerting • Audio attention signal and vibration cadence • Presentation • Functionality and features of the mobile device after the receipt of the alert message will be CMSP and mobile device specific • A subscriber has many other sources to obtain verification of the alert as well as up-to-the-minute detailed information, including NOAA All-Hazards Weather Radio, local media outlets, social networking, the Internet, including information sources available on their handsets today (software applications): • Access to web pages (e.g., mobile.weather.gov, local media/newspapers) • Applications (e.g., iNWS, MyCast, AccuWeather, carrier-specific applications) • Streaming audio & video services • Access to local & national radio via streaming audio (e.g. AOL Radio, iHeartRadio, FlyCast, XM Radio mobile, Slacker)

6. CMAS Standards Documents are available via: http://www.atis.org/docstore/ Joint ATIS/TIA CMAS Mobile Device Behavior Specification (J-STD-100) Joint ATIS/TIA Federal Alert Gateway to CMSP Gateway Interface Specification (J-STD-101): Note this is the so-called CMAS “C-interface”. Joint ATIS/TIA Federal Alert Gateway to CMSP Gateway Interface Test Certification Specification (in development) ATIS CMAS via GSM/UMTS Cell Broadcast Service Specification (ATIS-0700006) ATIS Implementation Guidelines and Best Practices for GSM/UMTS Cell Broadcast Service (ATIS-0700007) ATIS Cell Broadcast Entity (CBE) to Cell Broadcast Center (CBC) Interface Specification (ATIS-0700008) ATIS CMAS via Long Term Evolution (LTE, in development) 3rd Generation Partnership Project Cell Broadcast Specifications (published)

7. FEMA Adopts C-Interface Specification • The standard for the interface between the Federal Alert Gateway and the Service Provider Gateway was published last November following a 22-month joint industry-government standards effort “This is a huge milestone in the implementation of CMAS, and we could not have reached it without the leadership and patience of our industry partners. … I look forward to continuing our work together and have no doubt that we will successfully serve the public through our partnership in the coming months.” Denis Gusty Deputy Director Office for Interoperability and Compatibility U.S. Department of Homeland Security Science and Technology

8. CMAS Timeline Toward Deployment On Target!

9. Benefits of CMAS • CMAS uses the standardized Cell Broadcast Technology that is specified in the GSM, UMTS, CDMA and future cellular technologies • CMAS via Cell Broadcast is supported by all stakeholders – operators, handset vendors & infrastructure vendors • Cell broadcast does not require a separate broadcast network or receiver in the handset • Uses existing deployed infrastructure enhanced to support cell broadcast • Cell broadcast has been deployed worldwide and is proven for mass notification services, unlike point-to-point or unicast services • Cell Broadcast uses the existing cellular the over-the-air control channel structure • Cell Broadcast is an inherent part of cellular technology • Will be integrated as part of normal handset processing functions, including the user interface • Will be integrated into the power management mechanisms on the mobile device • Standardized solution takes into account the needs of all users, providing a consistent mobile device behavior experience across all operators: • Standard alert tone and vibration cadence • Common display and storage method • CMSAAC User Needs Group developed the recommendations for the CMAS alert message text after long consideration • Took into account special needs users, as well as the general population

10. Cell Broadcast • Cell Broadcast • You may see it referred to as “Short Message Service – Cell Broadcast” or “Broadcast Text” • Don’t confuse this with point-to-point text messaging • Cell Broadcast broadcasts messages to all devices capable of receiving the messages within the broadcast area • GSM/UMTS/LTE - Messages can be up to 15 “pages” of up to 93 characters per page • Minimally affected by traffic load, thus has higher chance of being usable during a disaster with high traffic loads on the network Mobiles in Broadcast Area Receive Alert Broadcasting Alert Alert Area Cell Broadcast Center Not Broadcasting Alert

11. CMAS Architecture Common Alerting Protocol (CAP) CMAS Protocol

12. Alert Aggregator Function • Authorization and authentication of 50,000+ alert initiators nationwide • Potential of 4,000+ interfaces • All messages attributed reliably to an individual sender • All messages accepted from individuals holding a specified credential or from a certified system which required individual credentials

13. How CMAS Fits into FEMA iPAWS/DM-Open CMAS

14. Scope & Definition of CMAS Alerts • A CMAS Alert Message processed by a Participating CMS Provider must not exceed 90 characters of alphanumeric text • Generated by the Federal Alert Gateway based on information in the received CAP message • Is an effective limit to allow the message to be delivered and actually be read • Expect that as CMAS providers eventually deploy technologies capable of messages of more than 90 characters, additional alert message elements will be implemented • Three classes of alerts: • Presidential • Imminent Threat Alert • Child Abduction Emergency or AMBER Alert • Only alerts that are imminent threat to life & property will be delivered to mobile devices • Notification service not information service • Subscribers are more likely to opt out if they are bombarded by minor notices, and may fail to notice a truly serious alert • Inclusion of minor events would be an unnecessary burden on the CMS provider infrastructure

15. CMAS Alert Message Content • Format designed to ensure that the most critical information is succinctly and clearly communicated in a manner most compatible with the technical attributes of wireless networks • Contents of the message: • What’s Happening (Event Type or Event Category ) • Area affected (in this area) • Recommended action (Response description) • Expiration time with time zone (Represented as a distinct time – e.g., until 09:30 AM EDT) • Sending Agency (agency type, i.e. police, fire, national weather service, etc.) • Per FCC rules, message does not contain phone numbers or URLs • Would encourage mass access of the wireless network causing severe network congestion • Responsibility for the content of alerts will remain with initiators and the federal government—not wireless carriers

16. Thank you Contacts: Peter Musgrove Chair, ATIS WTSC G3GSN Peter.musgrove@att.com Brian K. Daly Director, Core & Gov’t/Regulatory Standards, AT&T brian.k.daly@att.com

17. Backup

18. WARN Act Overview • “Warning, Alert, and Response Network Act” • U.S. Congress Passed the WARN Act as Part of SAFE Port Act on September 20, 2006 • Signed by U.S. President George W. Bush on Friday October 13th, 2006 • Required the FCC to Establish a Commercial Mobile Service Alert Advisory Committee (CMSAAC) within 60 days of enactment • First Meeting was December 12, 2006; final meeting October 3, 2007 • Membership by appointment of the FCC Chairman • Tasked for development of system-critical recommendations

19. WARN Act Timeline

20. WARN Act Requirements • Voluntary  Commercial Mobile Service Providers (CMSP) are required to make an Election to Transmit or Not Transmit Emergency Alerts in September 2008 • Elections can be “in whole or in part” • If elect not to transmit, must notify subscribers and provide notification at point-of-sale • If elect to transmit, must comply with standards, protocols, procedures, and regulations adopted by FCC • For CMSPs that Elect to Transmit Alerts: • Presidential-level Alerts must be transmitted • May offer subscriber opt-out capability for other classes of alerts • No Fee for Service • Transmission in languages in addition to English to the extent practical and feasible • Liability Protections, including: • “any act or omission related to or any harm resulting from the transmission of, or the failure to transmit, an emergency alert”

21. FCC First Report & Order Rules • Requires CMSP to provide a CMSP Gateway • must provide secure, redundant, and reliable connections to receive Alert Messages from the Federal alert gateway • Support CMSP “profile” on Federal Alert Gateway • support the defined CMAS “C” interface and associated protocols • Defined three classes of alerts: • Presidential • Imminent Threat • Child Abduction Emergency • CMAS Alert is 90 English Characters containing: • Event Type; Area Affected; Recommended Action; Expiration Time (with time zone); and Sending Agency • Embedding a phone number or URL is prohibited • CMSP is not required to perform any formatting, reformatting, or translation of an Alert Message • except for transcoding a text, audio, video, or multimedia file into the format supported by mobile devices • Multilanguage  English only required • Support while Roaming • If roaming agreement in place and CMSP and mobile device supports CMAS • Pre-emption of calls in progress • CMAS shall not pre-empt an active voice or data session • Standardized Audio Attention Signal and Vibration Cadence on mobile devices • Geo-targeting to the county level is minimum requirement • Delivery technology “Reference Points D and E protocols are defined and controlled by each Participating CMS Provider”

22. FCC Second Report & Order - Testing • Required Monthly Test (RMT) • Issued by Federal Alert Gateway over the “C” interface • CMSP shall schedule distribution of the RMT to their CMAS coverage area over a 24 hour period commencing upon receipt of the RMT at the CMS Provider Gateway • CMSP shall determine the method to distribute the RMTs • may schedule over the 24 hour period the delivery of RMTs over geographic subsets of their coverage area to manage traffic loads and to accommodate maintenance windows • May forego an RMT if: • the RMT is pre-empted by actual alert traffic • if an unforeseen condition in the CMS Provider infrastructure precludes distribution of the RMT • Subscriber’s mobile devices do not have to be able to receive the RMT • we may provide mobile devices with the capability of receiving RMT messages • in GSM/UMTS cell broadcast, we can control reception by use of the Message Identifier • Must retain an automated log of RMT messages received by the CMSP Gateway from the Federal Alert Gateway • In addition to the RMT, a CMSP must participate in periodic testing of the interface between the Federal Alert Gateway and its CMS Provider Gateway • This periodic interface testing is not intended to test the CMSP infrastructure nor the mobile devices but rather is required to ensure the availability/viability of both gateway functions

23. FCC Third Report & Order • CMSPs election to participate occurred on September 8, 2008. • CMSP development, testing & deployment starts 10 months after “Government Interface specification” is issued by FEMA • CMSPs have 18 months for development, testing, and deployment following the 10 month interval defined above. • Federal Alert Gateway and Alert Aggregator should collaborate with participating CMSPs to test the CMAS.

24. FCC Third Report & Order – Elect Not to Transmit “in whole” or Transmit “in part” • CMSP shall provide clear and conspicuous notice, which takes into account the needs of persons with disabilities, to new subscribers of its non-election or partial election to provide Alert messages at the point-of-sale • The point-of-sale includes stores, kiosks, third party reseller locations, web sites (proprietary or third party), and any other venue through which the CMS provider’s devices and services are marketed or sold

25. FCC Third Report & Order – Subscriber Opt-out • CMSAAC recommended subscribers be provided a simple way to opt out of CMAS alerts except for Presidential alerts • CMSPs may provide subscribers with the option to opt out of both, or either, the “Child Abduction Emergency/AMBER Alert” and “Imminent Threat Alert” classes of Alert Messages • “Imminent Threat” defined by specific severity-urgency-certainty values in the alert message • CMSPs shall provide their subscribers with a clear indication of what each option means, and provide examples of the types of messages the customer may not receive as a result of opting-out