Understanding CMAS Requirements & Implementation: A Comprehensive Overview

1. CMAS Is Coming Latest Information from the FCC and CMAS Forum for Rural & Regional Carriers An RCA Webinar, in cooperation with RTG July 28, 2010 Sponsored by:

2. The Commercial Mobile Alerting SystemTechnical Rules Presentation to RCA July 28, 2010 Jeffery Goldthorp Public Safety and Homeland Security Bureau Federal Communications Commission

3. The WARN Act • Purpose • To establish a framework by which CMS providers may voluntarily transmit emergency alerts to their subscribers. • Process • Established the Commercial Mobile Service Alert Advisory Committee (“CMSAAC”) to develop and recommend “system-critical recommendations” to the FCC. Submit such recommendations to the FCC within one year of statute enactment. (The Commission establish the CMSAAC, which held its first meeting on December 12, 2006 and submitted its recommendations to the Commission on October 12, 2007). • Within 180 days of submission of the CMSAAC’s recommendations, the FCC must adopt technical standards, protocols, processes and other technical recommendations necessary to enable CMS provider emergency alert capabilities. (The Commission adopted and released the CMAS First Report and Order on April 9, 2008). • Within 90 days of FCC adoption of technical requirements (i.e., July 2008), the FCC must adopt rules requiring noncommercial educational or public broadcast stations to install necessary equipment to enable distribution of geographically targeted alerts by CMS providers. • Within 120 days of FCC adoption of technical requirements (i.e., August 2008), the FCC must adopt rules allowing CMS licensees to transmit emergency alerts to their subscribers. CMS licensees that elect to transmit emergency alerts must do so in a manner consistent with the FCC’s rules. • Within 30 days after the Commission issues rules for CMS licensees to transmit emergency alerts, CMS licensees must inform the Commission whether or not they plan to participate in the CMAS. CMS licensees who choose not to participate in whole or in part will have to notify new and existing subscribers of their decision.

4. Commercial Mobile Services Alerting Advisory Committee • Required to submit recommendations for technical requirements by October 12, 2007. • 43 members, including • Public safety organizations (e.g., APCO, International Association of Fire Chiefs, Contra Costa County, CA); • Wireless carriers and organizations (4 major wireless carriers, CTIA, Rural Cellular Association); • Equipment manufacturers/vendors (e.g., Motorola, Ericsson, Nortel, Nokia, Qualcomm); • Broadcast associations (e.g., NAB, Florida, Texas and Michigan State Broadcasters, Association of Public TV Stations); • Organizations representing people with disabilities (e.g., WGBH National Center for Accessible Media); • Federal Stakeholders (e.g, FEMA, NOAA, NCS); • Other experts • Report delivered October 12, 2007.

5. Alert Delivery CMSP Administered Alert Origination Alert Authentication and Processing Government Administered CMAS First Report and OrderCMAS Architecture

6. CMAS First Report and OrderCMAS Architecture Alert Delivery CMSP Administered Alert Origination Alert Authentication and Processing Government Administered Federal Agencies Local EOC State EOC

7. CMAS First Report and OrderCMAS Architecture Alert Delivery CMSP Administered Alert Origination Alert Authentication and Processing Government Administered Federal Agencies Local EOC State EOC A B Alert Aggregation Alert Gateway

8. CMAS First Report and OrderCMAS Architecture Alert Delivery CMSP Administered Alert Origination Alert Authentication and Processing Government Administered Federal Agencies Local EOC State EOC C A CMSP Gateway B Alert Aggregation CMSP Infrastructure Alert Gateway Mobile Device

9. CMAS First Report and OrderFederal Government Role • The CMAS First Report and Order adopts the architecture proposed by the CMSAAC, i.e., that a Federal Government entity aggregate, authenticate, and transmit alerts to the CMS providers. • A critical requirement for CMS Providers • FEMA has declared their intention to assume the role of Alert Aggregator/Gateway.

10. CMAS First Report and Order Major ConclusionsGeneral • CMS Providers are the conduit for messages. Message content is determined by the alert originator. • Maintain technologically neutral stance regarding alert delivery technology. • No specific technology required or excluded. • Give CMS Providers discretion to innovate in this area. • Decline to adopt detailed “C” interface specifications. • Federal entity unknown at time Order was issued. • Text only in first generation. • Other service profiles possible in later generations. • 90 character limit.

11. CMAS First Report and OrderTechnologically Neutral Alert System • The WARN Act does not require the establishment of any specific technology to be used for the CMAS. • Paging carriers already provide point to multipoint services, using technologies such as ReFLEX and POCSAG (Post Office Code Standardization Advisory Group), to reach many subscribers at the same time and therefore appear well-positioned to participate in CMAS. • Despite potential drawbacks, SMS text messaging may offer a viable, short-term delivery method for electing CMS providers that do not yet have a point-to-multipoint text messaging capability. • CMSAAC noted that technologies such as MediaFLO and DVB-H “may provide supplemental alert information,” but recommended that they should not be considered as part of the CMAS.

12. CMAS First Report and Order Major ConclusionsMobile Device Functions • Authenticate interactions with the CMS Provider infrastructure. • Monitor for CMAS alerts. • Maintain the audio and mechanical (i.e., vibration) indicators that the subscriber has indicated as options when an alert is received by the mobile device.

13. CMAS First Report and Order Major ConclusionsCMS Provider Gateway • Manage individual CMS Provider elections to deliver alerts. • Formulate the alert in a manner consistent with the individual CMS provider’s available delivery technologies. • Map the alert to the associated set of cell sites/paging transceivers • Handle congestion within CMS Provider infrastructure

14. CMAS First Report and Order Major ConclusionsScope and Definition of Alerts • CMAS intended for severe events. • The following alerts categories are set forth in the Order: • Presidential • Alert would direct mobile device user to other sources of media for more information. • Imminent Threat • Urgent • Severe • Immediate • AMBER

15. CMAS First Report and Order Major ConclusionsAlert Message Elements • Supports CAP field mapping into alert text. • Required message elements: • Event Type or Category • Area Affected • Recommended Action • Expiration Time (with time zone) • Sending Agency • Messages that contain URLs or telephone numbers are not to be transmitted. • Free-form text alerts also supported. • Included as a CAP parameter. • 90 character limit.

16. CMAS First Report and Order Major ConclusionsGeo-Targeting • County-level geo-targeting required. • Subject to RF coverage limitations. • Driven by capabilities of current technology and desire to expedite deployment. • CMS Providers permitted, but not required, to deliver alerts to geographic areas smaller than the county.

17. CMAS First Report and Order Major ConclusionsMeeting User Needs • Common Polyphonic Alerting Tone • Serves the needs of visually impaired and users more generally. • Common Vibration Cadence • Serves the needs of the hearing impaired.

18. CMAS First Report and Order Major ConclusionsMultiple Languages • English is the only language required in first generation CMAS. • Supporting additional languages at this stage may: • Increase message latency. • Impact system capacity. • Further study is needed on this issue.

19. CMAS First Report and Order Major ConclusionsRoaming • Participating CMS Providers must transmit emergency alerts to users roaming on their networks. • Users with mobile devices capable of processing alerts will receive them. • Users roaming on networks operated by non-participating CMS Providers will not receive alerts.

20. The Commercial Mobile Alerting SystemParticipation and Customer Notice Rules Presentation to RCA July 28, 2010 Gregory Cooke Policy Division Public Safety and Homeland Security Bureau Federal Communications Commission

21. CMAS Third Report and OrderMajor Conclusions • Released on August 7, 2008 • Implemented section 602(b) of the WARN Act • Established timeline under which participating CMS providers must begin CMAS deployment • Mandated requirements regarding how and when CMS providers must elect to provide CMAS • Mandated how CMS providers must notify customers about their decision to provide or not provide CMAS

22. CMAS Third Report and Order CMSAAC Deployment Timeline

23. CMAS Third Report and Order Revised Deployment Timeline The CMSAAC had based its proposed deployment timeline upon WARN Act mandated deadlines CMS Provider Election Assumption that government deliverables would conform to its timeline. FEMA would be the Alert Aggregator/Gateway FEMA would provide the Government Interface Specifications by January, 2008 It was not until May 30, 2008 that FEMA announced that it would perform the CMAS Alert Aggregator/Gateway function FEMA had not made the Government Interface specifications available by the time the 3rd R&O was released.

24. CMAS Third Report and Order Revised Deployment Timeline • The Third Report and Order revised the timeline recommended by the CMSAAC and adopted by the Commission in prior orders. • CMS providers must begin to develop and test the CMAS no later than ten months from the date FEMA makes the Government Interface specifications available. • At the end of this 10-month period, participating CMS providers shall begin an eighteen month implementation and deployment period before the CMAS can be made available to the public. • 18 month implementation and deployment period still allows more than 24 months from the date the Government Interface specifications would be available for deployment to occur.

25. CMAS Third Report and OrderImportant Dates • September 8, 2008 • CMS providers required to elect whether to provide CMAS in whole or in part no later than September 8, 2008. (date imposed by WARN Act). • Timeline (and perhaps Congress) assumed that CMAS industry standardization would be complete and that CMAS would be ready for development, testing and deployment. • By 9/8/2008, FEMA had yet to deliver “C” Interface specs. • Absent completion of standardization, election was more to architecture than to actual delivery of alerts to customers • For Election Date, Commission created special docket for CMAS election. (PSHSB Docket No. 08-146.) • As of January 15, 2009, the Commission had received 482 election filings representing 611 CMS licensees. 119 would participate in whole, 27 in part, and 465 would not participate.

26. CMAS Third Report and OrderImportant Dates • December 7, 2009 • FEMA (as the Federal Alert Aggregator and Alert Gateway provider) made the Government Interface Design (“C” interface) specifications available. • Original timeline scheduled this for January, 2008, with industry standardization to be complete six months later. • Deadlines needed to be moved accordingly • 10 month deadline for Participating CMS providers to initiate development, testing and deployment moved from November, 2008, to October 2010. • Deadline for actual CMAS deployment moved from October, 2010, to April, 2012

27. CMAS Third Report and OrderImportant Dates • October 7, 2010 • Section 10.11 of the CMAS rules (47 CFR § 10.11) requires that a "participating CMS provider shall begin an 18 month period of development, testing and deployment of the CMAS in a manner consistent with the rules in this part no later than 10 months from the date that the Federal Alert Aggregator and Alert Gateway makes the Government Interface Design specifications available." • October 7, 2010= 10 months + 12/7/09 • No reporting obligation or deployment requirement. The date is merely a pacing benchmark to the April 2012 deadline.

28. CMAS Third Report and OrderImportant Dates • April 7, 2012 • Deadline for participating CMS providers to develop and deploy the CMAS. • 18 months after date for participating CMS providers to begin CMAS development, testing and deployment. • The system must be deployable by April, 2012.

29. CMAS First Report and Order CMS Participation Obligations • § 10.320 Provider Alert Gateway Requirements. • This section specifies the functions that each Participating Commercial Mobile Service provider is required to support and perform at its CMS provider gateways. • (a) General. The CMS provider gateway must provide secure, redundant, and reliable connections to receive Alert Messages from the Federal alert gateway. Each CMS provider gateway must be identified by a unique IP address or domain name.

30. CMAS First Report and Order CMS Participation Obligations(cont.) • § 10.320 Provider Alert Gateway Requirements. (cont.) • (b) Authentication and Validation. • Communication w/ Federal Alert Gateway. Includes error messages when alert fails • (c) Security. • CMS provider gateway must support standardized IP-based security mechanisms such as a firewall, and support the defined CMAS “C” interface and associated protocols. • (d) Geographic Targeting • CMS Provider Gateway must be able to map alert to coordinates in CMS provider network corresponding to coordinates in alert. Currently only to county level

31. CMAS First Report and Order CMS Participation Obligations(cont.) • § 10.320 Provider Alert Gateway Requirements (cont.) • (e) Message Management. • (1) Formatting. • No obligation to touch alert, just to format into what is supported by mobile devices. • (2) Reception. • Must be able to stop and start Alert deliveries from the Federal alert gateway to the CMS provider gateway • (3) Prioritization. • First in/first out except for Presidential alert. • (4) Distribution. • CMS Provider must employ one or more gateways. • (5) Retransmission. • Manage distribution and congestion w/in network

32. CMAS First Report and Order CMS Participation Obligations(cont.) • 10.320 Provider Alert Gateway Requirements (cont.) • (f) CMS Provider Profile • The CMS provider gateway will provide profile information on the CMS provider for the Federal Alert Gateway to maintain. • This profile information must be provided by an authorized CMS provider representative to the Federal Alert Gateway administrator. • The profile information must include the data listed in Table 10.320(f) and must comply with the following procedures: • (1) The information must be provided 30 days in advance of the date when the CMS provider begins to transmit CMAS alerts. • (2) Updates of any CMS provider profiles must be provided in writing at least 30 days in advance of the effective change date.

33. CMAS First Report and Order CMS Participation Obligations(cont.) • § 10.330 Provider Infrastructure Requirements • Infrastructure functions are dependent upon the capabilities of the delivery technologies implemented by a Participating CMS Provider. (a) Distribution of Alert Messages to mobile devices. (b) Authentication of interactions with mobile devices. (c) Reference Points D (the interface between a CMS Provider gateway and its infrastructure) and Reference Point E (the interface between a provider’s infrastructure and mobile devices including air interfaces). Each is defined and controlled by each Participating CMS Provider. • CMS Providers’ distribution methods is technology neutral, but must comply with these rules.

34. CMAS First Report and Order CMS Participation Obligations(cont.) • Although alert distribution w/in CMS provider network is technology neutral, gateway function must be consistent w/ “C” interface requirements • There is no prohibition against outsourcing gateway or even infrastructure distribution functions • CMS providers would still be obligated to comply with rules

35. CMAS Third Report and Order CMSP Election Withdrawal • WARN Act - §602(b)(2)(D) • (D) WITHDRAWAL; LATE ELECTION.—The Commission shall establish a procedure— • (i) 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; • (ii) for a commercial mobile service licensee to elect to transmit emergency alerts at a date later than provided in subparagraph (A); and • (iii) 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 • CMAS Rules – 47 CFR § 10.220 • "A CMS provider that elects, in part or in whole, to transmit CMAS Alert Messages may withdraw its election without regulatory penalty or forfeiture if it notifies all affected subscribers as well as the FCC at least sixty (60) days prior to the withdrawal of its election

36. CMAS Third Report and Order Customer Notice • No customer notice required for participation • 47 CFR §10.220 - Customer notice for withdrawal • In the event that a carrier withdraws from its election to transmit CMAS Alert Messages, the carrier must notify each affected subscriber individually in clear and conspicuous language citing the statute. • Such notice must promptly inform the customer that he or she no longer could expect to receive alerts and of his or her right to terminate service as a result, without penalty or early termination fee. • Such notice must facilitate the ability of a customer to automatically respond and immediately discontinue service.

37. CMAS Third Report and Order Customer Notice(cont.) • What if there are no customers for CMAS? Service is not due until 2012. • Rules require a withdrawing carrier to notify all existing and prospective affected subscribers, and allow existing subscribers to cancel their service without any contract penalty after the system is live, which by current scheduling, will be in 2012. • The rule requires notifying affected customers that they "no longer could expect to receive alerts." A customer "no longer could expect to receive alerts" only if CMAS were commercially available and only if they had a handset capable of receiving the alerts, neither of which is true today for any subscriber of any CMS provider. • Notice only to FCC • File withdrawal in PSHSB Docket No. 08-146

38. CMAS is Coming ! Latest information from FCC & CMAS Forum for RCA carriers Presented by: Joe Cobbs VP – Business Development Velleros, Inc. (972) 941-3161 jcobbs@velleros.com Velleros Proprietary and Confidential

39. Agenda Latest from CMAS Forum Schedule information Considerations for the RCA carrier Phased approach for deployment

40. CMAS Current Status • Implementation phase has started for ‘Opt-In’ wireless carriers • ‘C’ interface standard was released in Dec 2009 • Clock started – should begin testing within 10 months by Oct 2010 • Need a CMSP Gateway and a means to transmit • Other CMAS project decisions • ‘A’ interface standard finalized for aggregation • FEMA gateway deployment well underway targeting availability by Feb 2011 • ‘Opt-out’ wireless carriers have a decision to make: • If you don’t opt-in, you’ve chosen not to participate • This will be a competitive disadvantage exploitable by other carriers … • Tier 1 operators and several regional & rural carriers are already in the process of deploying & testing

41. Schedule Proposal 4/7/2012 9/8/2008 10/7/2010 12/7/2009 10 months Testing & Development 18 months Implementation & Deployment Go Live Date FCCTest Deadline C Interface Approved Operators Notify FCC of Participation Starting Point Begin testing Phase 1 Cell Broadcast testing Phase 2 C Interface testing Notify Subs If Not Compliant Phased Approach 2/2011 10/2006 FCC Timeline FEMAGateway Online WARNAct Passed by Congress

42. Carrier Planning for CMAS Plan, Engineer, Deploy, Test, Launch

43. Carrier Network Considerations • Cell Broadcast Upgrade • MSCs & switching equipment likely to require software upgrade • Standard interface: • GSM TS 3.14 • CDMA IS-824 • Multi-vendor environment • Hybrid GSM/CDMA networks • Impact on Other Network Elements • SS7 network interconnection • Test interoperability with CMSP gateway • Other delivery methods • SMSC throttling • Voice connectivity

44. Carrier Handset Considerations • Handset changes for CMAS implementation: • Only handsets with Cell Broadcast channels activated will receive CB messages • Support for CMAS-specific alerting tones & cadences • Evaluate timing & availability of CB-capable handsets • Limited number required for test purposes • Align availability & activation with CMAS launch • Subscribers should have capability to opt-out of imminent threat and amber alerts via phone menu • What to consider prior to handset ubiquity: • Alternative & secondary alerting means • Opt-in for interested customers

45. Carrier CMSP Gateway Considerations • Critical new network technology to integrate: • Multiple delivery methods including Cell Broadcast • Multiple aggregation methods including new ‘C’ Interface • Flexible system platform to support new capability and additional apps • Platform robustness to fit in existing network • Carrier-grade reliability required • Must support network throughput management • Alternative alerting capability is critical to service launch • Solution must be ‘future-proof’ • Flexible ‘D’ Interface to support concurrent access technologies • Security and authentication should be state-of-the-art • Opportunity to mitigate cost by leveraging platform for new business models • CMSP Gateway decision – Hosted v. In-Network

46. Phased Implementation Approach Testing starting point - “CMAS Ready” Community Notification NWS Op t - I N P o r t a l NWS Aggregator Filter for CMAS Priority Alerts County Level GeoTargeting Notify Opt-in Subs

47. Phased Implementation Approach Testing 1st Phase - “CMAS Ready” Community Notification with Cell Broadcast NWS NWS Op t - I N P o r t a l NWS Aggregator Op t - I N P o r t a l NWS Aggregator Filter for CMAS Priority Alerts Filter for CMAS Priority Alerts County Level GeoTargeting County Level GeoTargeting Notify Opt-in Subs Notify Opt-in Subs Broadcast over Cell Sites

48. Phased Implementation Approach Testing 2nd Phase – CMAS Notification with Cell Broadcast & C Interface FEMA GW NWS NWS Op t - I N P o r t a l Op t - I N P o r t a l NWS Aggregator “C” Interface Op t - I N P o r t a l NWS Aggregator Filter for CMAS Priority Alerts Filter for CMAS Priority Alerts County Level GeoTargeting County Level GeoTargeting County Level GeoTargeting Notify Opt-in Subs Notify Opt-in Subs Notify Opt-in Subs Broadcast over Cell Sites Broadcast over Cell Sites An effective method to deploy CMAS within schedule while minimizing risk

49. Summary • Opt-in carriers need a plan to meet the Oct 2010 testing deadline • Need to consider impact to: • Network equipment • Handsets • CMSP Gateway • Carriers have time to fully implement in an efficient & effective way • Phased approach is best to mitigate risk • Cell Broadcast & FEMA Gateway interoperability • Support for CMAS is critical for regional carriers • Important to be viewed as the responsible community provider to the local subscriber base CMAS is coming ! Be ready.

50. Q & A • Now is your chance to ask questions to any of today’s presenters and panelists! • On the right side of your screen, please type your question into the chat box • Questions will be read aloud by RCA and answered by the panel • Thank You!