CMAS Is Coming

CMAS Is ComingLatest Information from the FCC and CMAS Forum for Rural & Regional Carriers

An RCA Webinar, in cooperation with RTG July 28, 2010

Sponsored by:

The Commercial Mobile Alerting SystemTechnical Rules

Presentation to RCA

July 28, 2010

Jeffery GoldthorpPublic Safety and Homeland Security BureauFederal 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

o Public safety organizations (e.g., APCO, International Association of Fire Chiefs, Contra Costa County, CA);

o Wireless carriers and organizations (4 major wireless carriers, CTIA, Rural Cellular Association);

o Equipment manufacturers/vendors (e.g., Motorola, Ericsson, Nortel, Nokia, Qualcomm);

o Broadcast associations (e.g., NAB, Florida, Texas and Michigan State Broadcasters, Association of Public TV Stations);

o Organizations representing people with disabilities (e.g., WGBH National Center for Accessible Media);

o Federal Stakeholders (e.g, FEMA, NOAA, NCS);o Other experts

Report delivered October 12, 2007.

5

CMAS First Report and OrderCMAS Architecture

Alert Authentication and ProcessingGovernment Administered

Alert DeliveryCMSP AdministeredAlert

Origination

6



Alert DeliveryCMSP Administered

State EOC

Local EOC

Federal Agencies

Alert Origination

7


Alert Aggregatio

n Alert Gateway


Alert DeliveryCMSP AdministeredA

B

State EOC

Local EOC

Federal Agencies

Alert Origination

8


Alert Aggregatio

n Alert Gateway

CMSP Gateway

CMSP Infrastructure

Mobile Device


Alert DeliveryCMSP AdministeredA

C

B

State EOC

Local EOC

Federal Agencies

Alert Origination

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.

The Commercial Mobile Alerting SystemParticipation and Customer Notice Rules

Presentation to RCA

July 28, 2010

Gregory CookePolicy DivisionPublic Safety and Homeland Security BureauFederal 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

Oct 07 Nov 10

Jan 08 Apr 08 Jul 08 Oct 08 Jan 09 Apr 09 Jul 09 Oct 09 Jan 10 Apr 10 Jul 10 Oct 10

Apr-08CMAS Report & Order

Issued by FCCOct-08

Industry Standardization Complete

Oct-07 - Oct-08Industry Standardization

Oct-08 - Oct-1024 month CMAS Development & Testing

Oct 08 - Apr 1018 month CMAS Development & Testing

Initial CMSP Testing& Deployment Occurs

In This Timeframe

Oct 07CMSAAC

RecommendationsIssued

Government Alerting Network & Alert

Gateway Ready for Testing

Oct 07 - Apr 08FCC CMAS

Report & Order

Sep 08CMSP Election

Jan 08Government Interface

Design Specs Available

Government Milestones and Activities are in Red

Industry Milestones and Activities Are in Blue

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


§ 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


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


§ 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


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

Velleros Proprietary and Confidential

CMAS is Coming !Latest information from FCC & CMAS

Forum for RCA carriers

Presented by:Joe CobbsVP – Business DevelopmentVelleros, Inc.(972) [email protected]

Agenda

• Latest from CMAS Forum• Schedule information• Considerations for the RCA carrier• Phased approach for deployment

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

Phased ApproachPhased Approach

FCC Timeline

FEMAGatewayOnline

2/2011

CInterfaceApproved

12/7/2009

10 months

Testing & Development

18 months

Implementation & Deployment

OperatorsNotifyFCC of

Participation

9/8/2008

FCCTest

Deadline

10/7/2010

Go LiveDate

4/7/2012

Starting PointBegin testing

Phase 1Cell Broadcast

testing

Phase 2C Interface

testing

WARNAct

Passed byCongress

10/2006

NotifySubsIf Not

Compliant

Schedule Proposal

Carrier Planning for CMAS

Plan, Engineer, Deploy, Test, Launch

Carrier Network Considerations

• Cell Broadcast Upgrade– MSCs & switching equipment likely to require software upgrade– Standard interface:

o GSM TS 3.14o 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

o SMSC throttlingo Voice connectivity

• 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

Carrier Handset Considerations

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

Phased Implementation ApproachTesting starting point - “CMAS Ready” Community Notification

NWS

NWSAggregator

County Level GeoTargeting

Opt-IN

P o r t a lNotify

Opt-inSubs

Filter for CMAS Priority Alerts

Phased Implementation ApproachTesting 1st Phase - “CMAS Ready” Community Notification with Cell Broadcast

NWS

NWSAggregator


Opt-IN

P o r t a lNotify

Opt-inSubs


NWS

NWSAggregator



Broadcast over Cell

Sites

Notify Opt-inSubs

Opt-IN

P o r t a l

Phased Implementation Approach

An effective method to deploy CMAS within schedule while minimizing risk

FEMA GW

“C” Interface


Broadcast over Cell

Sites

Notify Opt-inSubs

Opt-IN

P o r t a l

Testing 2nd Phase – CMAS Notification with Cell Broadcast & C Interface

NWS

NWSAggregator


Opt-IN

P o r t a lNotify

Opt-inSubs


NWS

NWSAggregator



Broadcast over Cell

Sites

Notify Opt-inSubs

Opt-IN

P o r t a l

• 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.

Summary

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!

2010 Business & Technical Conference

Register today for RCA’s fall conference! October 12-14, 2010 in Myrtle Beach, SC Go to www.rca-usa.org for more info!

http://www.rca-usa.org/

CMAS Is Coming

Documents

cms licensees

cmas forum

emergency alerts

cms providers

commission issues rules

cmsaacs recommendations

technical standards

targeted alerts