Commercial Mobile Alert System - GSM

Transcription

1 An Overview of the Commercial Mobile Alert System - GSM August 27, 2008 Brian K Daly Gary K Jones Doug Rutledge

2 Agenda Regulatory Aspects WARN Act and FCC Rules Definition of a CMAS Alert CMAS Architecture t CMAS Deployment Scenarios CMAS Mobile Devices GSM/UMTS Cell Broadcast for CMAS CMAS Industry Standards Effort What s Next for CMSPs?

3 Regulatory Aspects: WARN Act and FCC Rules

4 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 13 th, 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

5 WARN Act Timeline Oct-06 WARN Act Enactment Dec-06 FCC Establishes Advisory Committee Apr-07 FCC Defines Unserved Rural Communities Oct-07 Advisory Committee Recommendations to FCC Jan-08 FCC Issues Rules on Broadcasters Apr-08 FCC Adopts Standards Aug-08 FCC Issues Rules Allowing Mobile Operators to Transmit Alerts Sep-08 Operators File Elections on EAS Service Jan-07 Apr-07 Jul-07 Oct-07 Jan-08 Apr-08 Jul-08 Oct-08 Oct-06 Dec-08 Dec-06 - Oct-07 Development of System-Critical Recommendations By Advisory Committee Oct-07 - Apr-08 FCC Defines Commercial Mobile Service Regulations Apr-08 - Aug-08 FCC Amends Commercial Mobile Service License

6 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, and emergency alert

7 Commercial Mobile Service Alert Advisory Committee Purpose Develop and submit to FCC recommendations regarding technical standards and protocols to enable participating CMSPs to transmit emergency alerts to subscribers Recommendations due to FCC one year from WARN Act enactment (delivered October 12, 2007) Comprised of a wide range of stakeholders, including representatives from state, local, and tribal governments; vendors, developers and manufacturers; technical experts; other governmental agencies; and wireless service providers

8 CMSAAC Organization Advisory Committee (approx 40 Representatives) Chair Project Management Group Chairman Martin (or Designee) Communications Technology Group Alerting Gateway Alerting Interface User Needs Group Group Group David Webb Anthony Melone Brian K. Daly Jonathan Werbell/Gary Jones (FEMA) (Verizon Wireless) (AT&T) (NYC/T-Mobile)

9 FCC CMAS First Report & Od Order WARN Act required that, by April 9, 2008 (within 180 days of receipt of the CMSAAC s recommendations), the Commission complete a proceeding to adopt: relevant 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 that voluntarily elect to transmit emergency alerts. First Report & Order Issued April 9, 2008 FCC generally adopted the CMSAAC Recommendations FCC adopted the CMAS architecture proposed by the CMSAAC FCC conclude that a Federal Government entity should aggregate, authenticate, and transmit alerts to the CMS providers Initial implementation timeline clause (section 10.11) Participating CMS Providers must comply with these rules no later than 10 months from the date the FCC announces the selection of a Federal Government entity to perform the Alert Aggregator and Alert Gateway functions required to implement the CMAS Language concerning and ultimately changed to: Notwithstanding anything in this part to the contrary, a Participating CMS provider shall begin development and testing 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.

10 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 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 p an active voice or data session Standardized Audio Attention Signal and Vibration Cadence on mobile devices 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 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

11 FCC CMAS Second Report & Od Order WARN Act also required the FCC to adopt rules requiring: Non-commercial educational (NCE) and public broadcast television i station ti licensees to 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 commercial mobile service providers that have elected to transmit emergency alerts... 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 FCC Second Report & Order addressed these rules, and was released July 8, 2008

12 FCC Second Report & Order NCE/PBS NCE & Public Broadcast Television Stations require to install equipment and that will provide the ability to enable the distribution of geodcmas alerts to targeted participating CMS providers Consistent with the First Report & Order provide a redundant, alternate path by which geo-targeted alerts may be received by participating p CMS providers does not require participating CMS providers to use this alternate path to receive geo- targeted alerts Federal Alert Gateway C Interface CMSP Gateway CMSP Network NCE or PBS DTV Station Alternate C Interface Path

13 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

14 FCC Third Report & Order CMSPs election to participate shall occur on September 8, CMSP development, testing & deployment starts 10 months after Government Interface specification is issued by FEMA. If FEMA Government Interface specification is not issued by December 31, 2008, FCC will reconvene emergency meeting of the CMSAAC to address the issuance of the Government Interface specification. CMSPs have 18 months for development, testing, and deployment following the 10 month interval defined above. Federal Alert Gateway and Alert Aggregator g should collaborate with participating CMSPs to test the CMAS.

15 FCC Third Report & Order - Election CMSP that elects to transmit CMAS Alert Messages, in part or in whole, shall electronically file with the Commission a letter attesting that the Provider: (1) agrees to transmit such alerts in a manner consistent t with the technical standards, protocols, procedures, and other technical requirements implemented by the Commission; and (2) commits to support the development and deployment of technology for the C interface, the CMS provider Gateway, the CMS provider infrastructure, and mobile devices with CMAS functionality and support of the CMS provider selected technology CMSP that elects not to transmit CMAS Alert Messages shall file electronically with the Commission a letter attesting to that fact

16 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 of 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

17 Subscriber Notification in whole NOTICE TO NEW AND EXISTING SUBSCRIBERS REGARDING TRANSMISSION OF WIRELESS EMERGENCY ALERTS (Commercial Mobile Alert Service) [[CMS provider]] presently does not transmit wireless emergency alerts. Notice required by FCC Rule 47 C.F.R (Commercial Mobile Alert Service).

18 Subscriber Notification in part NOTICE REGARDING TRANSMISSION OF WIRELESS EMERGENCY ALERTS (Commercial Mobile Alert Service) [[CMS provider]] has chosen to offer wireless emergency alerts within portions of its service area, as defined d 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 [CMS provider] service area. For details on the availability of this service and wireless emergency alert capable devices, please ask a sales representative, or go to [[CMS provider s URL]]. N ti i db FCCR l 47CFR (C i l M bil Notice required by FCC Rule 47 C.F.R (Commercial Mobile Alert Service).

19 FCC Third Report & Order Notification of Existing Subscribers for non-participation CMSP that t elects not to transmit CMAS Alert Messages, in part or in whole, shall provide clear and conspicuous notice, which takes into account the needs of persons with disabilities, to existing subscribers of its non-election or partial election to provide Alert messages by means of an announcement amending the existing subscriber s service agreement Prepaid subscribers if a mailing address is available, the CMSP shall provide the required notification via U.S. mail if no mailing address is available, the CMSP shall use any reasonable method at its disposal to alert the customer to a change in the terms and conditions of service and directing the subscriber to voice-based notification or to a website providing the required notification

20 FCC Third Report & Order when do carrier s notify subscribers? Sixty (60) days following an announcement by the Commission i that t the Alert Aggregator/Gateway system is operational and capable of delivering emergency alerts to participating CMS providers

21 FCC Third Report & Order Withdrawal of Election CMSP may withdraw its election without regulatory penalty or forfeiture if it notifies all affected subscribers as well as the Federal Communications Commission at least sixty (60) days prior to the withdrawal of its election the carrier must notify each affected subscriber individually in clear and conspicuous language citing the statute 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

22 FCC Third Report & Order Subscriber Opt-out t 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

23 Latest CMAS Deployment Timeline from the FCC Rules Begin Subscriber Notification

24 Definition of a CMAS Alert

25 What Are CMAS Emergency Alerts? Only alerts that are immediate, severe, or likely threat to life, health or property p will be delivered to mobile devices Limited to imminent threat to life & property Minimize the cry wolf syndrome Notification service not an information service Limitations it ti on number of text t characters that t can be broadcast and displayed Wireless alerts are only one component to an overall effective emergency notification strategy Supplements existing emergency notification systems such as Radio/TV-based EAS and National Weather Service All-Hazards Radio Limited to commercial mobile service providers Includes Pagers and cellular mobile devices Excludes Radio broadcasters, TV broadcasters, Satellite broadcasters Public Safety communications systems (e.g., 800 MHz systems) Data-only devices such as air cards MediaFLO, DVB-H, IPTV

26 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 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

27 CMAS Text Service Profile Initial CMAS text profile is a 90 English character text-based message Text is viewed as the lowest common denominator Must account for all mobile devices, low end to high end Streaming audio & video, multimedia defined for future consideration Text string generated by the Alert Gateway from the Common Alerting Protocol (CAP) elements Tornado Warning in this Area until 7:00pm PDT Take Shelter Now NWS Free form text capability is provided (especially for Presidential, Amber Alerts), but a federal policy needs to be developed on what should be sent

28 Alert Class Alert class is narrowly tailored to those emergencies where life or property is at risk, the event is likely to occur, and some responsive action should be taken Specifically, an Imminent Threat Alert must meet separate thresholds regarding urgency, severity, and certainty Based on permissible values in the CAP message received at the Alert Gateway Urgency Immediate (i.e., responsive action should be taken immediately) or Expected (i.e., responsive action should be taken soon, within the next hour) Severity. Extreme (i.e., an extraordinary threat to life or property) or Severe (i.e., a significant threat to life or property) Certainty. t Observed (i.e., determined to have occurred or to be ongoing) or Likely (i.e., has a probability of greater than fifty percent). That is, the event must have occurred, or be occurring (Observed), or be more likely to occur than not (Likely).

29 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.) Alert Gateway may employ a generic statement such as The President has issued an emergency alert. Check local media for more details 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 should remain with initiators and the federal government not wireless carriers

30 Concerns Regarding Lack of Social Studies Limited social science or focus group studies have been performed What will be the end user reaction to receiving these alert notifications? End Users clogging emergency services or operator customer care services for more information Reaction when receiving alerts while driving, for example S i l di i d f ll d d Social studies are required to fully understand impact of the CMAS service offering

31 CMAS Architecture

32 CMAS Architecture Common Alerting Protocol (CAP) CMAS Protocol

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

34 Message Origination Trust Model (FEMA) All messages attributed reliably to an individual sender All messages accepted from individuals id holding a specified credential or from a certified system which required individual credentials All messages must be countersigned by a second credentialed sender. CMSAAC recommended that a process be established by which credentials can be certified upon demonstration of identity, responsibility and capability. Identity, responsibility and capability must be recertified annually. All credentials will expire in 12 months. All messages entered into the system will be logged, this log will be maintained for a reasonable period of time to support an audit. Digital signatures will be bound to the message and carried from the alert originator to the Alert Gateway. Message transport layer from the alert originator to the Alert Gateway will utilize an existing open non-proprietary transport standard and shall be Internet Protocol based.

35 Key Federal Alert Gateway Functions Authentication of interactions and validation of alert messages from Federal Alert Aggregator Convert received CAP message into Reference Point C message for CMSP Gateway Generate 90 character English text alert message Process alert messages in a first in first out (FIFO) queuing method Except for Presidential-level alert which will be immediately moved to the top of the queue & processed before all other non-presidential alerts

36 Key CMSP Gateway Functions Authentication of interactions and validation of alert messages from Federal Alert Gateway Will not perform any formatting, re-formatting, or translation of the alert messages other than transcoding for air interface requirements Process alert messages in a first in first out (FIFO) queuing method Except for Presidential-level level alert which will be immediately moved to the top of the queue and processed before all other non-presidential alerts

37 C Interface Each individual CMSP Gateway shall be able to receive alerts from the Federal government alert gateway over a secure interface (i.e., C Interface ) XML-based protocol defined in the CMSAAC Recommendations Currently being standardized in ATIS and TIA (more later) The CMSP Gateway will be required to, among other things, to: Manage the CMS provider s election to provide alerts Format alerts received in a manner consistent with the CMS provider s available delivery technology Map alerts to the associated set of cell sites/paging transceivers Manage congestion within the CMS provider s infrastructure

38 Structure of C Interface Message CMAC_Alert_Attributes XML based One Alert Attribute segment One or more Alert Info segments One or more Alert Area segment per Alert Info segment Zero or more Alert Resources segments per Alert Info segment CMAC_protocol_version CMAC_sending_alert_gateway_id CMAC_message_identifier CMAC_referenced_message_identifier (optional) CMAC_special_handling CMAC_sender CMAC_sent_date_time CMAC_status CMAC_message_type CMAC_note (optional) CMAC_original_cap_alert_uri CMAC_Alert_Info CMAC_category CMAC_event_code (optional) CMAC_response_type (optional) CMAC_severity CMAC_urgency CMAC_certainty CMAC_expires_date_time CMAC_sender_name (optional) CMAC_text_language CMAC_text_encoding CMAC_text_alert_message_length length CMAC_text_alert_message CMAC_web (future) CMAC_Alert_Area CMAC_area_description CMAC_polygon (optional) CMAC_circle (optional) CMAC_cmas_geocode CMAC_gnis (optional) CMAC_Resource CMAC_ resource_description (future) CMAC_mime_type (future) CMAC_resource_size (future) CMAC_resource_uri (future) CMAC_resource_digest (future)

39 CAP Message to C Interface Message

40 Example Scenario Call Flow Call flow for new emergency alert message to be broadcast Reference Point A 1. Alert created Government Alerting Network Reference Point C 2. Alert validated 3. Alert converted 4. CMAM sent to AT&T AT&T Network Reference Point E Mobile Device End User 5. CMAM validated 6. CMAM acknowledged 7. Geo-targeting performed 8. Broadcast CMAM 9. Monitor for CMAM 10. Alert received, alarm issued & alert text displayed 11. Behavior of Mobile Device Beyond This Point Dependent on Mobile Device Vendor Implementations

41 Geo-Targeting Mapping of alert area to cell sites t ll it Red polygon is alert area Yellow cell sites are those providing coverage within polygon Minimum geotargeting requirement is county level If alert area crosses multiple counties, alert may be sent to each county Federal Alert Gateway will supply geotargeting information to CMSPs CMSP can choose to broadcast to smaller geo-target area, i.e. only to alert area indicated d by polygon or circle

42 Commercial Mobile Alert Delivery Technology FCC Rules based upon service profiles No specific delivery technologies specified by FCC Text service profile required Audio, video, and multimedia service profiles for future study Point-to-point delivery technologies such as SMS or MMS not feasible or practical Especially on a nationwide, statewide, or large city scale Point-to-point will quickly congest a network, resulting in significant message delays or messages not delivered, as well as denying voice service Broadcast technology required for effective distribution Uni-direction broadcast of information No response or acknowledge from mobile device Broadcast to all subscribers in alert area

43 Why Not Point-to-Point Technologies? Point-to-point or unicast delivery technologies not feasible nor practical for CMAS for the following reasons: Can experience significant ifi delivery delays Can result in network and radio interface congestion to the point of blocking voice calls Lack security and can be easily spoofed Lack geo-targeting capabilities because it is targeted to phone numbers instead of a specific alert area Lack emergency alert specific audio attention signal & thereby emergency alerts can not be distinguished from normal SMS message traffic Lack support of roamers

44 Anticipated Traffic Volume Vast majority of emergency alerts issued by National Weather Service (NWS) Flash Flood Warnings & Tornado Warnings account for approximately all warning issued in ,050 Flash Flood Warnings issued in ,189 Tornado Warnings issued in 2006 Approximately 1,200 child abduction emergency/amber Alerts issued per year on a national basis Initial CMAS alerts for a single language of English assumed to be 25,000 per year on a national basis Based upon above statistics & factor of uncertainty Volume expected to increase due to additional usage of alert system Volume expected to increase if additional language beyond English are supported

45 Roaming Roamers can be supported if Mobile device is Cell Broadcast capable Cell Broadcast is activated on mobile device Appropriate Cell Broadcast channels/message IDs activated t CMAS functionality on mobile device highly recommended Special CMAS audio attention signals & vibration cadences Presentation of alert message text without leading overhead control indicators Detection and suppression of presentation of duplicate alert messages

46 CMAS Deployment Scenarios

47 Deployment Scenarios FCC Rules require that a commercial mobile service provider who elects to transmit emergency alerts can elect to transmit the CMAS alerts in whole or in part In whole or in part include the following: 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 Alerting Interface Domain Operator Domain Alerting Gateway network Domain X X

48 Likely Deployment Scenario

49 CMAS Mobile Devices

50 Mobile Device Requirements New CMAS compliant mobile devices are required 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 Legacy deployed mobile devices are not required to be supported At a minimum, new CMAS functionality is needed on future mobile devices New mobile devices will be introduced by normal market mobile device lifecycle replacement

51 Key Mobile Device CMAS Functionality Monitor and detect broadcasted emergency alert messages Present emergency alert message to subscriber Presentation controlled by subscriber opt out options on mobile device Presentation including CMAS audio attention signal and vibration cadences as well as textual component of CMAS alert message. Detect and suppress presentation of duplicate emergency alert messages Duplicates can be either from same or different cell sites No acknowledgement or response to received wireless alert message CMAS Alert Reception/Presentation shall not preempt active voice call or data session

52 Subscriber Opt-Out Options Three classes of Commercial Mobile Alert Service (CMAS) Message categories: Presidential-level Imminent threat to life and property Child Abduction Emergency or AMBER Alert Presidential-level alert messages must always be presented Recommended subscriber options: Opt out of all messages except Presidential messages Receive only the most extreme alert messages Choice on whether or not to receive AMBER Alerts Subscriber options are maintained on the mobile device for Cell Broadcast

53 Alert Audio Attention Signal & Vibration Cadence (1 of 3) Reproduction of existing EAS audio attention signal on mobile devices most recognizable method to notify American public of wireless emergency alert Emergency Alert System (EAS) EAS uses two tone system for audio alerts which is combination of 853Hz and 960Hz sine waves EAS audio attention signals on commercial broadcast stations are 8 to 25 seconds in duration NOAA Weather Radio warning alarm tone Single tone for NOAA warning alarm tone for NOAA Weather Radios and commercial broadcast stations is 1050Hz NOAA warning alarm tone is 8 to 10 seconds

54 Alert Audio Attention Signal & Vibration Cadence (2 of 3) Recommended temporal pattern of audio attention signal One long tone of approximately 2 seconds Followed two short tones of approximately 1 second each Approximately ½ second gap between tones Entire sequence is repeated twice with approximately ½ second between repetitions Mobile device manufacturer specific For devices which have polyphonic capabilities, audio attention signal should consist of the two EAS tones For devices which have only single frequency alert tone capability, audio attention signal be in the low frequency range below 2.5 khz

55 Alert Audio Attention Signal & Vibration Cadence (3 of 3) Vibration cadence for wireless emergency alerts Should be noticeably different from default cadence of mobile device Should be similar to temporal pattern of audio attention signal Mobile device manufacturer specific If both audio attention signal and vibration cadence available Modes do not need to be activated simultaneously Modes do not have to be synchronized Comply with user s s settings in mobile device Silent mode Vibrate only Can not select alert audio attention signal or vibration cadence for any other mobile device function

56 Support of Individuals With Special Needs Mobile Device Behavior recommendations include emergency alert support for individuals with special needs CMAS audio attention signal for emergency alerts CMAS vibration cadence for emergency alerts Some handset models capable of text to speech functionality Clear & simple language whenever possible, with minimal use of abbreviations

57 Battery Life CMSAAC analysis confirmed that battery life is a potential issue with Cell Broadcast Each technology implements text broadcast messaging differently Each technology is deployed with different hardware and software, as well as, different standards releases Battery life impact of CMAS on a state of the art deployment of infrastructure and portable devices targeting optimized battery life could be as high as 40% or more Confirming other industry reports Impact to mobile device battery life can be managed by the CMSP through careful selection of the system parameters For example, use of GSM/UMTS Cell Broadcast DRX capability Factors outside the CMSP control impacting battery life include: Number of languages supported Number of alerts sent Alert duration

58 GSM/UMTS Cell Broadcast for CMAS

59 Cell Broadcast Support of CMAS requires no changes to 3GPP Cell Broadcast specifications Cell Broadcast best solution currently available in standards Limited to text only messages Supported by both GSM & UMTS standards State of the Union of Cell Broadcast Service (CBS) Limited deployments and trials in the U.S. Most handsets deployed today do not have cell broadcast capability CBS menus are not visible to subscribers Software for CBS may or may not exist in the handset CBS in handsets have never been tested or validated

60 Cell Broadcast Basics Cell Broadcast is a GSM/UMTS feature that allows a text broadcast to all mobile terminals in a designated geographical area Broadcasts areas can be one cell, many cells, a Location Area, every cell connected to a BSC/RNC, cells in several BSCs/RNCs, or the entire network Cell Broadcast is an unconfirmed push service, meaning that the originator of the message does not know who has received the message Cell broadcast messages can only be received when the mobile is in CS idle mode or PS-Connected Mode UMTS Implementation of the terminal determines how the user accesses the message

61 Cell Broadcast Message Each message is assigned an numeric identifier by the operator Serial number parameter Message serial number is part of the message broadcast Each message can contain up to 15 pages (segments) Each page can contain 93 7-bit characters Maximum message length 1,395 7-bit characters The 90 character English CMAS text message only requires one Cell Broadcast page

62 GSM/UMTS Cell Broadcast Architecture t

63 GSM/UMTS CMAS Cell Broadcast Architecture t

64 Cell Broadcast Architecture Elements Base Station / Radio Network Controller (BSC/RNC) Provides the interface to CBC for storage of the cell broadcast messages and routing of the cell broadcast message to the appropriate BTS/Node B(s) for delivery over the CBCH or CTCH Cell Broadcast Center (CBC) Provides the interface for CBE clients, it handles the administration of all CB messages it receives from the CBEs including mapping of geographic areas to cell ids and delivers them to the correct BSC/RNC(s) for broadcast. Cell Broadcast Entity (CBE) Service provider or operator CB client application that may send CB messages using the interface provided by the CBC. For wireless emergency alerts, the CBE is the CMSP Gateway

65 CMAS Industry Standards Effort

66 CMAS Industry Standards Development Joint ATIS/TIA CMAS Standards Development Specification of C interface between the Federal Alert Gateway & CMSP Gateway Includes requirements on the Federal Alert Gateway to support operations on the C interface Specification of mobile device behavior for CMAS functionality Both these specifications are technology neutral ATIS WTSC s CMAS via GSM/UMTS Cell Broadcast Service Specification Specification for Reference Points D and E within CMSP infrastructure and to the mobile device Mapping of CMAS onto existing GSM/UMTS cell broadcast Goal is no impact to existing cell broadcast standards This specification is in support of GSM/UMTS Note: TIA is also developing a specification for CMAS via CDMA Cell Broadcast GSM-NA Defines assignments of GSM/UMTS Cell Broadcast Message Identifiers for support of U.S. Commercial Mobile Alerts All specifications targeted to be complete in November, 2008

67 GSM CMAS Cell Broadcast Architecture t WTSC CMAS Stds Joint ATIS/TIA Spec Stds Spec 3GPP & Best Practices Doc 3GPP Joint ATIS/TIA 3GPP Stds Spec CMAS Cell Broadcast Message Defined in WTSC CMAS Stds Spec CMAS Cell Broadcast Message Identifiers Defined in GSM-NA

68 UMTS CMAS Cell Broadcast Architecture t Specifications same as for GSM CMAS Cell Broadcast Architecture except as noted below: WTSC CMAS Stds Spec 3GPP & Best Practices Doc Alert Gateway CMSP Gateway Cell Broadcast Center (CBC) RNC UTRAN Node B Node B Mobile Device Mobile Device C 1 IuBC Iub Uu

69 Federal Government Involvement in Joint CMAS C Interface Standards Work Involvement by Federal Alert Gateway developers is critical to the completion of the Joint ATIS/TIA CMAS C interface standard Developing an interoperable interface requires technical representatives for both sides of the interface participate in the development of the interface protocol A list of open issues and questions have been identified by the Joint ATIS/TIA standards group which need to be addressed with the Federal Alert Gateway designers in order to progress the standards Governmental stakeholders, namely those who can represent the Federal Alert Gateway standardization di ti interests, t have been invited it to attend and provide input into the Joint ATIS/TIA standards meetings Both Government & Industry stakeholders must concur that the Federal Alert Gateway and the CMSP Gateway will be designed d to the C interface standards being developed by the Joint ATIS/TIA committee Development of the Federal Alert Gateway and the CMSP infrastructure t must be aligned with CMSP development to allow for joint interoperability testing

70 Proposal Collaboration for C Interface Specification Completion September 2008 ATIS/TIA completes the "C" interface draft specification from the CMSP Gateway perspective This is a version which the industry has resolved all technical issues from the CMSP side, but will contain a list of open issues and questions the industry has to FEMA for the Federal Alert Gateway October, November, December 2008 Joint industry/fema meetings/conference calls to address technical issues and questions and update the draft specification accordingly By December 31, 2008, FEMA issues Government Interface specification based on FEMA-Industry collaboration December 2008/January 2009 Joint meeting with FEMA and industry to perform a final review of the spec with all issues addressed and incorporated February 2009 Final specification released to industry for ballot April 2009 Ballot comments resolve, additional ballot if required under ATIS/TIA rules May/June 2009 Final specification published

71 Relationship of CMAS & 3GPP Standards d Japanese-driven Earthquake & Tsunami Warning System (ETWS) as defined in 3GPP is not supported in the U.S. CMAS Future alignment of CMAS with 3GPP Public Warning System (PWS) standards is to be determined

72 What s Next for CMSPs?

73 What do CMSPs have to do next? September 8, 2008 CMAS Election Day! When the Federal Alert Gateway is available for delivering CMAS alerts (as announced by the FCC), CMSPs must notify subscribers as required under the FCC rules Dependent on the CMSP election in whole or in part If elect to transmit in whole or in part Develop, test & deploy CMSP Gateway, Cell Broadcast Center, and Cell Broadcast capability in the BSC/RNC and radio network Deploy CMAS-compliant handsets If elect not to transmit Notify subscribers per FCC rules