Alert Gateway Group (AGG)

1. Alert Gateway Group (AGG) Status Report to the Commercial Mobile Service Alert Advisory Committee July 18, 2007 Anthony Melone, AGG Leader

2. AGG Current Status • Submitted two drafts on Alert Gateway requirements. Outline of requirements is as follows: • Alert Gateway Architecture • Security • System capacity and Performance • Interfaces and Protocols • Protocol Mapping • CMS Provider Profiles • Reporting • Performance Testing

3. Summary of Draft Conclusions • Alert Gateway Architecture • Flexible Architecture • Support Multiple CMSP Gateways per CMSP • Geo-redundant • Security Requirements • Authentication and Authorization • At both B and C interfaces • Assumed that B Interface is within government defined “trust-model” • C interface will support non-proprietary standards-based security(e.g. IPSec, SSL) • Support SSH-based tunnels for secure remote access • Gateway locations will be physically secured

4. Summary of Draft Conclusions • System Capacity and Performance • Capacity • Based on historical data the Alert Gateway should be designed to support • 25,000 CMA’s per year. • Design peak rate of 300 alerts per second. • Throttling • The Alert Gateway shall support configurable throttling parameters specified by the CMS Providers (i.e. CMS Service Profile) • The Alert Gateway shall also support general flow control. (i.e. the number of alerts issued to the same county in a given time interval) • Buffering • The Alert Gateway shall support two queues per CMSP Gateway • One queue for buffering the Presidential alerts • Another queue for buffering non-Presidential alerts • The processing of Presidential alerts takes priority over non-Presidential alerts • Non-Presidential alerts are processed sequentially as received

5. Summary of Draft Conclusions • Interface and Protocols • B Interface • Documented, Non-proprietary standards based (likely IP) • CAP v1.1 protocol (XML) • C Interface • Documented, Non-proprietary standards based (likely IP) • XML based protocol • Protocol Mapping • CAP Element to “CMAS” Element (w/CTG, AIG) • Translation Logic • Defined Default Values • CAP Element to Text Verbatims (w/UNG, AIG)

6. Summary of Draft Conclusions • CMSP Profiles • Geographic Territory/CMSP GW assignment • Service Profiles supported • Geo-Location Preferences (FIPS, LAT/LON, etc) • Language Preferences • Throttling Parameters • Reporting • Message Logs • On-line (30 days) • Archived (36 months) • General System & Performance Reporting

7. Summary of Draft Conclusions • Performance Testing • Connectivity (C interface) • Periodic “keep alive” messaging • Functional (Alert GW through CMSP GW) • Alert GW originated Test Messages • Accepted by CMSP GW, but not sent to end user device • Support Overall System Testing (TBD) • Likely will be treated as a normal message with appropriate mapping of CAP element to CMAS element to maintain “test” identity of alert

8. Deliverables (30-45 days) • Refine/Finalize Alert GW Filtering Logic • New alerts must meet the imminent threat to life and property criteria • Update & Cancel message logic to account for changes in severity, urgency, certainty, geography. • Adding default expiration time to CMA message if not provided byalert originator • Other Default Parameters • Refine/Finalize Alert GW Element Mapping Logic • Construct CMA messages from the CAP alert message based on the requirements from CTG, AIG and UNG • Specify detailed logic/mapping table to convert a CAP message to an appropriate CMA message to the CMSP GW • Need all required “B” interface CAP elements and their code values identified • Need all required “C” interface message parameters and their code values identified • Need CAP element to Verbatim recommendations • Include examples of translated CAP to CMA messages for variousalert types (e.g. Presidential alerts, AMBER, Test Alerts)

9. Future Deliverable Dates • August 9th: Third Draft Submission • September 7th: Final Draft Submission