CMAS Is Coming
Latest Information from the FCC and CMAS
Forum for Rural & Regional Carriers
An RCA Webinar, in cooperation with RTG
Sponsored by:
July 28, 2010
The Commercial Mobile Alerting System
Technical Rules
Presentation to RCA
July 28, 2010
Jeffery Goldthorp
Public Safety and Homeland Security Bureau
Federal Communications Commission
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.
3
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.
4
CMAS First Report and Order
CMAS Architecture
Alert Origination
Alert Authentication and Processing
Government Administered
5
Alert Delivery
CMSP Administered
CMAS First Report and Order
CMAS Architecture
Alert Origination
Alert Authentication and Processing
Government Administered
Federal
Agencies
Local EOC
State EOC
6
Alert Delivery
CMSP Administered
CMAS First Report and Order
CMAS Architecture
Alert Origination
A
Alert Authentication and Processing
Government Administered
B
Federal
Agencies
Alert
Aggregation
Alert
Gateway
Local EOC
State EOC
7
Alert Delivery
CMSP Administered
CMAS First Report and Order
CMAS Architecture
Alert Origination
A
Alert Authentication and Processing
Government Administered
C
Alert Delivery
CMSP Administered
CMSP Gateway
B
Federal
Agencies
Alert
Aggregation
CMSP Infrastructure
Alert
Gateway
Local EOC
Mobile Device
State EOC
8
CMAS First Report and Order
Federal 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.
9
CMAS First Report and Order
Major Conclusions
General
 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.
10
CMAS First Report and Order
Technologically 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 wellpositioned 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.
11
CMAS First Report and Order
Major Conclusions
Mobile 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.
12
CMAS First Report and Order
Major Conclusions
CMS 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
13
CMAS First Report and Order
Major Conclusions
Scope 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
14
CMAS First Report and Order
Major Conclusions
Alert 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.
15
CMAS First Report and Order
Major Conclusions
Geo-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.
16
CMAS First Report and Order
Major Conclusions
Meeting 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.
17
CMAS First Report and Order
Major Conclusions
Multiple 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.
18
CMAS First Report and Order
Major Conclusions
Roaming
 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 nonparticipating CMS Providers will not receive
alerts.
19
The Commercial Mobile Alerting System
Participation and Customer Notice Rules
Presentation to RCA
July 28, 2010
Gregory Cooke
Policy Division
Public Safety and Homeland Security Bureau
Federal Communications Commission
CMAS Third Report and Order
Major 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
21
CMAS Third Report and Order
CMSAAC Deployment Timeline
Oct-07 - Oct-08
Industry Standardization
Oct-08 - Oct-10
24 month CMAS Development & Testing
Oct 07 - Apr 08
FCC CMAS
Report & Order
Jan 08
Apr 08
Oct 08 - Apr 10
18 month CMAS Development & Testing
Jul 08
Oct 08
Jan 09
Apr 09
Jul 09
Oct 09
Jan 10
Apr 10
Jul 10
Oct 10
Oct 07
Oct 07
CMSAAC
Recommendations
Issued
Nov 10
Government Alerting
Network & Alert
Gateway Ready for
Testing
Sep 08
CMSP Election
Apr-08
CMAS Report & Order
Issued by FCC
Oct-08
Industry Standardization
Complete
Jan 08
Government Interface
Design Specs Available
Initial CMSP Testing
& Deployment Occurs
In This Timeframe
Government Milestones and Activities are in Red
Industry Milestones and Activities Are in Blue
22
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.
23
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.
24
CMAS Third Report and Order
Important 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.
25
CMAS Third Report and Order
Important 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
26
CMAS Third Report and Order
Important 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.
27
CMAS Third Report and Order
Important 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.
28
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.
29
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
30
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
31
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.
32
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.
33
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
34
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
35
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.
36
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
37
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
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
Schedule Proposal
10/2006
9/8/2008
Operators
Notify
FCC of
Participation
4/7/2012
10 months
FCC
Timeline
WARN
Act
Passed by
Congress
2/2011
10/7/2010
12/7/2009
18 months
Testing &
Development
Implementation & Deployment
FCC
Test
Deadline
C
Interface
Approved
Starting Point
Begin testing
Phase 1
Cell Broadcast
testing
Phased Approach
FEMA
Gateway
Online
Phase 2
C Interface
testing
Go Live
Date
Notify
Subs
If Not
Compliant
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
o
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
o
o
SMSC throttling
Voice connectivity
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
Carrier CMSP Gateway Considerations
•
Critical new network technology to integrate:
–
–
–
•
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’
–
–
•
Multiple delivery methods including Cell Broadcast
Multiple aggregation methods including new ‘C’ Interface
Flexible system platform to support new capability and additional apps
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 Approach
Testing starting point - “CMAS Ready” Community Notification
NWS
NWS
Aggregator
Filter for CMAS
Priority Alerts
County Level
GeoTargeting
Notify
Opt-in
Subs
O
p
t
I
N
P
o
r
t
a
l
Phased Implementation Approach
Testing 1st Phase - “CMAS Ready” Community Notification with Cell Broadcast
NWS
NWS
NWS
Aggregator
Filter for CMAS
Priority Alerts
County Level
GeoTargeting
Notify
Opt-in
Subs
O
p
t
I
N
P
o
r
t
a
l
O
p
t
I
N
NWS
Aggregator
Filter for CMAS
Priority Alerts
P
o
r
t
a
l
County Level
GeoTargeting
Broadcast
over Cell
Sites
Notify
Opt-in
Subs
Phased Implementation Approach
Testing 2nd Phase – CMAS Notification with Cell Broadcast & C Interface
FEMA GW
NWS
NWS
NWS
Aggregator
Filter for CMAS
Priority Alerts
County Level
GeoTargeting
Notify
Opt-in
Subs
O
p
t
I
N
P
o
r
t
a
l
O
p
t
I
N
NWS
Aggregator
Filter for CMAS
Priority Alerts
P
o
r
t
a
l
County Level
GeoTargeting
Broadcast
over Cell
Sites
Notify
Opt-in
Subs
“C” Interface
O
p
t
I
N
P
o
r
t
a
l
County Level
GeoTargeting
Broadcast
over Cell
Sites
Notify
Opt-in
Subs
An effective method to deploy CMAS within schedule while minimizing risk
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.
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!