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