FINAL (8 Nov 2010, Updated 25 Aug 11)

Capabilities Document for

Air Mobility Command’s

Emergency Mass Notification System

8 November 2010 (Updated 25 Aug 11)

FINAL (8 Nov 2010, Updated 25 Aug 11)

1. Description of Services 1.1 Customer Requirements 1.1.1 Air Mobility Command (AMC) requires an Emergency Mass Notification System (EMNS) to support approximately 120,000 military, civilian, and contractor personnel stationed at AMC bases and facilities in the continental United States, with capabilities to support future implementation of a surge of personnel to meet worldwide mobility mission requirements. This service shall allow operators/controllers spread across multiple locations to initiate and manage emergency notifications to all personnel assigned to their respective subordinate units. 1.1.2 Objectives. Acquire the capability to notify AMC personnel en masse at base or unit level when emergency conditions exist or are imminent. Implement an enterpriselevel EMNS, leveraging existing investments and infrastructure procured to date. Seamlessly integrate and interoperate with other emergency notification systems currently in use at AMC bases. 1.1.3 Scope. The desired EMNS solution will be an enterprise-wide solution incorporating all personnel assigned to AMC bases and joint base installations for which AMC is designated the supporting command (JB McGuire-Dix-Lakehurst and JB Charleston. 1.2 EMNS Components 1.2.1 The system should be composed of the major components contained in paragraphs 1.2.2, 1.2.3, 1.2.4, 1.2.5, and 1.2.6. 1.2.2 Network Alerting System (NAS). A Network Alerting System with real-time response tracking, text messaging, and desktop audio/visual notifications to Customer personnel, ensuring anyone connected to the AMC (AMC-2K) and/or Air Force (AFNet) IP network via desktop, laptop, or any other networked device, would be notified within a maximum of 3 minutes of an alert being sent out, with responses from recipients captured and reported in real time to operators. (System Integrator can assume that for the purposes of desktop notifications, there are approximately 60 percent of assigned personnel on the Customer network at any given time.) 1.2.3 Telephone Alerting System (TAS). A capability to provide phone notification to Customer personnel utilizing an integrated phone alerting capability. 1.2.4 Unified Notification Management. A Unified Notification Management capability that includes the ability to (i) integrate with multiple notification delivery devices, (ii) initiate emergency alerts to any and all notification devices via single web-based interface, (iii) manage a single repository of emergency scenarios, (iv) enable real-time

FINAL (8 Nov 2010, Updated 25 Aug 11)

tracking and reporting, (v) manage permission-based access for operators, and (vi) integrate user data from disparate data sources such as Active Directory. 1.2.5 Personnel Alerting. Personnel Alerting capability that includes the ability for (i) personnel/users to self-update their information so as to maintain up-to-date contact information for emergencies, and (ii) track responses to alerts and provide reports that summarize units and individual personnel responses/status. 1.2.6 Giant Voice/Radio Broadcast Integration. Capability to activate and integrate with existing or future Giant Voice/Radio Broadcast systems at Customer locations. 1.2.7 Social Networking Media Integration. Capability to post alerts to social networking media such as Twitter or Facebook within required security parameters. 1.3 System Requirements 1.3.1 The system shall be based on a commercial-off-the-shelf (COTS) software product. 1.3.2 The system shall be capable of sending alert messages to end-users (recipients) via multiple delivery methods, including audio-visual network alerts to desktops and laptops via desktop popup, text alerts to mobile phones and pagers, text alerts to email clients, audio alerts to phones, audio alerts to existing outdoor public announcement (PA)/Giant Voice systems, and postings to social networking capabilities such as Twitter and Facebook (within required security parameters). The system needs to be extendable to support additional delivery methods in the future as may be required. 1.3.3 The system shall be capable of sending alert messages to target recipients according to hierarchical organizational structure (as would be imported from Active Directory), organizational roles, specific distribution lists (e.g., HAZMAT teams), dynamic groups created through on-the-fly queries of the user directory based on pre-defined queries, geographical locations (e.g., bases, zones within bases), specific mass notification devices and IP address ranges, as applicable. 1.3.4 The system shall centrally track, in real-time, all alerting activities for each individual recipient, including sending, receiving and responding to alerts, and will be able to generate tabular and graphical reports based on this information. 1.3.5 The system shall provide tools for personnel alerting, collecting personnel current status in cases of emergency, allowing users to update their status, and producing reports allowing operators to centrally track and drill down to status of personnel. 1.3.6 The system shall incorporate a pre-defined library of signals and messaging appropriate to Force Protection Conditions (FPCON), Information Operations Conditions (INFOCON), terror threats, watches, warnings, evacuation routes, battle staff directives, personnel recall, and other alerting information to meet Federal, “Sister Services,” and AMC base-specific warning and notification requirements.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.3.7 The system shall incorporate a web-based management and alert activation application through which all users, operators, and administrators will gain access to the system’s capabilities, based on their permissions and defined access policy. Such management application will incorporate management of the alert activation flow through all delivery methods, end-users management, operators’ permission and access, tracking and reporting, and all administrative aspects of the system. EMNS will integrate with existing base-level Giant Voice (GV), and allow centralized and "remote" activation of this capability as well. This requirement DOES NOT call for replacing on-site JITCcertified telephone alerting system (TAS) or GV but rather integrating with and activating existing JITC-certified TAS and GV systems. 1.4 Architecture Requirements 1.4.1 The System Integrator will provide an AMC enterprise-wide system capable of spanning multiple network domains with distributed permission-based access. The Operations Center/Command Post will maintain unrestricted global access and be able to alert all Customer personnel as well as define and manage emergency scenarios and procedures that will be shared throughout the system. The system shall also meet requirements of HSPD-5, Management of Domestic Incidents; AFI 10-801, Assistance to Civilian Law Enforcement Agencies; AFI 10-802, Military Support to Civil Authorities; and allow additional requirements of AFI 10-208, COOP Program. 1.4.2 The System Integrator will provide a COTS system that will be installed behind the Non-classified Internet Protocol Router Network (NIPRNet) firewall, and have a netcentric architecture supporting DoD networking standards and network security requirements. Specifically, the system shall utilize a web-based user interface, support service standard network ports and protocols, and provide open interfaces to support interoperability. The system must include provisions for secure communication, authentication, and encryption using DoD and industry-standard PKI-encryption technologies. The system must be compliant with Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) standards. Any desktop delivery capability must be Section 508 Compliant (for people with disabilities). A solution which is completely based on leased, or vendor hosted services is not appropriate due to OPSEC and physical security issues. The system will integrate with Unified Communication platforms such as Cisco Unified Communication or Microsoft Office Communication Server. 1.4.3 The system shall have an architecture allowing central alert activation, control, and management; such server(s) shall be deployed on-site and connected to the Customer network. 1.4.4 To leverage AMC’s existing investment and architecture, the Network Alerting System shall be interoperable with the various emergency notifications systems already deployed at AMC bases. The system shall support targeting of populace and triggering alerts in the respective EMNS from its consolidated web based console.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.4.5 The system shall support integration with centralized user directories, including specifically Active Directory. 1.4.6 The system shall support integration with multiple alert delivery systems, such as telephone alerting, radio pagers, television alerts, text mobile, Giant Voice, Emergency Alert System, and others. 1.4.7 The system shall provide for the capability to monitor and integrate with external event sources, such as weather alerts, and activating automatically alerts based on identifying a match with pre-defined conditions. 1.4.8 Integration shall be based on web services, XML over HTTP/S, and Common Alerting Protocol (CAP), and shall support secure integration and source authentication. 1.4.9 The integration interface with other notification delivery systems shall support, at a minimum, the following Application Program Interface (API) functions from the other notification delivery system: (i) activate a targeted alert, by fully specifying all alert parameters or activating a predefined alert; (ii) collecting alert distribution status (either as a summary status or on a more granular basis); (iii) aborting an activated alert (for all or only for specific target, as applicable). Once positive notification is obtained from the user, all other methods of notification shall cease. 1.4.10 The system shall support configurable automatic data archival by date-based business rules, allowing archiving of old data. The system shall support high availability and scalable server configurations to achieve high availability (i.e., no down time in case of failure in a single server) as well as support higher load scenarios (e.g., more users). The system will allow for a COOP (continuity of operations) site in an alternate location having 100 percent of the capacity of the primary site and the ability to provide all system functionality when the primary site is disabled. The data in the COOP site will be on-line synchronized with the primary site. 1.5 Notification Delivery Requirements 1.5.1 Desktop Notifications. The system shall activate audio/visual notifications on users’ computers connected to the network, as long as the end-user client software is installed on that computer, there is connectivity to the system server, and the user is targeted by the notification. Desktop client application shall communicate with the system over standard ports and protocols, and shall not require opening or configuring non standard ports in firewalls and proxies. The system shall be capable of delivering desktop notifications to all connected users’ desktops within the specified Maximum Desktop Notification Delivery Time. 1.5.2 Notifications shall appear as intrusive desktop popup(s) on the user’s desktop with associated audio, with no need for end-user intervention to receive the desktop notifications. The desktop popup(s) shall show on top of all other applications, and will

FINAL (8 Nov 2010, Updated 25 Aug 11)

be displayed until acknowledged by the end user, or the notification established time expires. If more than one notification is sent before acknowledged or cancelled, all notification popup(s) shall be displayed in a time-sequenced, tiered fashion. 1.5.3 Desktop notification may include a title text, body text, URL, audio, streaming audio, streaming video and images (e.g., logo), as well as response options (if defined for the notification). Desktop client shall support current SDC OS and Mac OS 10.6.3 Snow Leopard. 1.5.4 Desktop client application shall support authentication using DoD PKI client certificates stored as Electronic Data Interchange Personal Identifier (EDIPI) in DoD CACs, and using an operating system based authentication. 1.5.5 The system shall store-and-forward notifications to end-users, as long as the notification has not expired or been aborted. The store-and-forward capability shall cater to users who were not online when the notification was activated. 1.5.6 The system shall provide targeting notifications to recipients’ desktops based on logged in user identity (including Windows username, Windows domain name), based on machine name, and based on IP address. 1.5.7 No user shall get a specific notification more than once on their desktop. When a user is logged in to more than one workstation, the desktop notification will show on all logged in workstations. 1.5.8 The system shall provide a library of pre-defined HTML-based popup templates and audio signals to control the visual and audible aspects of the popup notification. Operators will be able to add or modify such templates. 1.5.9 Desktop client application shall support remote installation and updates via Microsoft Systems Management Server or similar enterprise IT Management tools as well as self-installation by an end-user. 1.5.10 The Desktop client or its installation procedure will allow blocking of permissions that allow the end user without workstation Administrator’s rights, to uninstall the client. 1.6 Telephony Voice Notifications 1.6.1 The system shall have the capability to send alerts to end-users as voice messages to land or mobile phones. The system shall provide text-to-speech capability for such voice telephony notifications. The system shall interface with the base switch. 1.6.2 The solution should support an integral telephone alerting capability using leased lines.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.6.3 The integral telephone alerting service capability should support calling at the specified rate of 120,000 phone calls (one-minute-long message) in 3 hours. 1.6.4 The integral telephone alerting service capability shall not require installation of additional telephony equipment on site and may utilize the base switch or other telephony system depending on site survey. The system shall have the capability to connect through IP to an external telephone alerting service provider or to designated service location. 1.6.5 Communication with the external telephone alerting service shall not compromise recipients’ details sensitivity, and shall communicate only the minimum data required to perform the telephony alerting flow; in no circumstance will any recipient’s personal information and contact details be stored on an ongoing basis external to the on-site alerting system. 1.6.6 Communication with the external telephone alerting service shall be secured and use standard ports and protocols. 1.6.7 The telephone alerting service shall be highly available and served from at least two remote and secured sites. 1.6.8 The system should support integration with the GFE telephone dialing system on site, to include via its API. The System Integrator shall specify the integration requirements with the GFE TAS equipment. 1.6.9 The system shall support multiple phone numbers per recipient. 1.6.10 The system shall be able to distinguish between a live person, answering machine, voice mailbox, or busy signal when delivering notifications. The system shall be able to leave a message on answering machines or voice mailbox with call-back details, as defined for the notification. 1.6.11 The system shall support PIN based authentication of recipients. 1.6.12 The system shall allow the user to select between multiple response options defined for the alert message using the phone keypad (DTMF). 1.6.13 The system shall track and report alert delivery progress to voice phone device, as well as the response option chosen by the recipient when recipient is reached by the system; in case no response options are provided, the system shall track acknowledge of the alert by the recipient. 1.6.14 The system shall have the capability to connect the recipient to a phone conference upon selection by the recipient of the appropriate response option.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.7 Mobile Text Messaging and Email Notifications 1.7.1 The system shall send notifications to end-users as text messages via email, SMS, or Blackberry messages. 1.7.2 When using SMS, a long message shall be automatically broken into multiple numbered sections. 1.7.3 The system shall track delivery progress and collected response options collected from end users receiving mobile text notifications or emails. 1.8 Public Communication Devices including Giant Voice 1.8.1 The system shall have the capability of interfacing with Giant Voice. 1.8.2 The system shall be capable of integrating with locally installed GFE GV and Radio Broadcast systems, covering internal and external PA systems. 1.8.3 The system shall support activation of Giant Voice messages, as specified for the activated notification message, using an XML-based CAP protocol. 1.8.4 Integration with GV and Radio Broadcast systems shall not replace the existing GV/Radio Broadcast activation method, but shall rather augment them for unified notification scenarios. 1.8.5 GV notification messages will specify the voice message to be activated, and optionally specific GV towers/sirens to be activated, for targeted activation. 1.8.6 The system shall support defining GV activation parameters as part of a predefined notification scenario, as well as setting up GV activation parameters on the fly. 1.8.7 The System Integrator shall provide a list of supported and documented GV/PA/ Radio Broadcast systems integrations, and shall specify integration requirements and capabilities. 1.9 Notifications to Cisco Unified Communication Manager (UCM) Connected VoIP Phones 1.9.1 The system shall have the capability of interfacing with Cisco Unified Communication Manager (UCM) VoIP Phones; capability outlined in this section is optional. As such, the Customer does not intend to procure this capability as part of this PWS, but does require that such capability be available in the system for subsequent procurement and/or upgrade.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.9.2 The system shall support integration with Customer furnished (GFE) Cisco Unified Communication Manager (UCM) to deliver notifications to connected Cisco Voice-overIP (VoIP) phones and regular phones. 1.9.3 The system shall support delivery of notifications to IP Phones and regular phones connected to the Cisco UCM infrastructure, supporting the same requirements for voice telephony notifications previously specified, with the capacity and specifications as available by the GFE Cisco UCM. 1.9.4 For the GFE Cisco IP Phones, the system shall support blast notification delivery to the phones’ display (not using the typical voice based dialing), including: 1.9.4.1 Displaying text, image, and color coding using pre-defined templates 1.9.4.2 Activating pre-defined audio and streaming text-to-speech audio, converting Cisco IP Phones to a PA system 1.9.4.3Displaying text response options and tracking user selected response options 1.10 Notification via Microsoft Office Communication Server (OCS) 1.10.1 The system shall have capability of interfacing with OCS. 1.10.2 The system shall support integration with GFE Microsoft Office Communication Server. 1.10.3 The system shall support delivery of notifications to IP phones and regular phones connected to the Microsoft OCS infrastructure, supporting the same requirements for voice telephony notifications previously specified, with the capacity and specifications as available by the GFE Microsoft OCS. 1.10.4 The system shall support specific OCS capabilities, including: 1.10.4.1 Delivery of text messages to OCS instant messaging clients (Microsoft Office Communicator, MOC) connected to the OCS platform, including displaying of response options and tracking of user selected response options. 1.10.4.2 Leverage OCS end users presence status for effective delivery. 1.10.4.3 Leverage OCS collaboration capabilities (voice conference, web conference, IM conference) in alerting scenarios. 1.10.4.4 Mixed mode conferences (MOC audio conference with regular phones), including calling targeted users to join them into the audio conference.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.11 Unified Notification Management 1.11.1 The system shall support a browser-based unified console for single activation of alerts across multiple delivery devices; selection of alerting devices will be based on user preference, operator selection, or scenario definition. 1.11.2 Supported delivery devices include network alerting to desktops, email, telephony, SMS/Text messaging, fax, TTY/TTD, Giant Voice/PA systems, VoIP, fire alarms, message boards, digital displays, kiosks, LMR, National Emergency Alert System, radio and cable TV, and video and sensor surveillance equipment. 1.11.3 The system shall support automatic conversion of a single alert message to appropriate format for each delivery device, including text-to-speech for applicable audio devices (e.g., telephony, sirens). 1.11.4 The system shall support telephony devices delivery escalation using business rules—if recipient does not respond to first device, try next one, and repeat as needed. 1.12. Scenarios and Notification Activation 1.12.1 The system shall support alert definition on-the-fly or based on pre-defined scenarios associated with actual operational and emergency procedures. Scenario definition includes alert content, alert duration, responses, targeted recipients, selected delivery devices and permitted operators, as well as per-device options. 1.12.2 The system shall include an out-of-the-box scenario library specific to the US DoD, including 100+ scenarios for FPCON, INFOCON, warnings and more. 1.12.3 The system shall support full alert lifecycle (begin time and end time including scheduled alerts) so recipients are notified only while emergency situation is in effect; the system shall allow aborting of a live alert, ceasing all delivery activities. 1.12.4 The system shall support re-occurring scheduled alerts. 1.12.4 The system shall support “stand-by” alerts to be approved before actual activation. 1.12.5 The system shall support coverage analysis for a specific alert, based on its target populace contact information and designated delivery devices. 1.12.6 The system shall support a web-based management system that allows views to all currently active alerts: -Scheduled alerts -Re-occurring alerts -Archived alerts.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.12.7 The system shall support a web-based management system that allows searching of alerts by: -Activation period -Alert category -Alert publisher. 1.13 Notification Targeting Methods 1.13.1 The system shall support targeting of recipients by distribution lists and groups, as dynamic lists (based on user data) or as static lists of users (“rosters”) that can be indefinitely nested. 1.13.2 The system shall support targeting of users by organizational hierarchy. 1.13.3 The system shall support targeting by dynamic query on-the-fly based on a combination of any user data fields, such as role, medical training level, location, or IP address. 1.13.4 The system shall support the ability to use custom attributes for targeting users by either pre-designating a custom attribute as targetable (i.e. “Target by Role”), or by utilizing logical constructs (AND/OR) for the purpose of selecting recipients for alert targeting, distribution lists, etc. 1.13.5 The system shall support targeting of personal and mass notification devices (such as sirens and display boards) using a geographical map-based interface or GEOBASE, enabling the selection of buildings, regions, or zones to be notified 1.13.6 For geo-targeting, the system shall support real world map (Geographical Information System (GIS)). 1.13.7 For geo-targeting, the system shall support GFE. A user who is a member of multiple targeting criteria shall be notified only once. The system shall support blocking delivery of alerts to designated groups of recipients, by any of the targeting methods. 1.14 Tracking, Reporting and Archiving 1.14.1 The system shall support one or more response options presented to recipients for selection and acknowledgement. The system shall support tracking and reporting of alert delivery and responses for each alert recipient and device. The report will provide timestamps for each recipient and device used. 1.14.2 The system shall show real-time aggregated Alert summary, providing graphical view (bar, graph, or pie charts) of total personnel targeted, sent, received acknowledgements and response options by count and/or percentage; reports shall show breakdown of response tracking and delivery status per device.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.14.3 Organizational hierarchy - Provide a detailed real-time graphical table analysis for total sent and received, including acknowledgements and specific response options. Organizational chart reports can be viewed within each level of the hierarchy and filter down to the member level as well as individuals within each grouping. 1.14.4 Distribution lists – detailed real-time graphical table analysis for total sent and received, including acknowledgements and specific response options. Each distribution list can be converted into a list of individual members by a specific response option. 1.14.5 Reports can be automatically archived for operator-defined timeframe or rulesbased. 1.14.6 Response tracking reports can be formatted for printing, or be exported to Microsoft Excel (XLS). 1.15 End User Management 1.15.1 The system shall provide web based recipient’s management capabilities including: viewing recipients, creating new recipients, editing recipient’s details, managing distribution lists (rosters), and importing and exporting recipients’ data. 1.15.2 The system shall support multiple phone numbers, emails or mobile phone numbers per recipient, which could be imported from enterprise personnel repositories (i.e., Active Directory) or from Comma Separated Value(CSV) files. 1.15.3 The system shall support the ability to define an unlimited number of additional user custom attributes of different types (Boolean, string, number, date-time, memo, single and multi pick-list). 1.15.4 The system shall allow mandating and assigning defaults for custom attributes; for example, role, rank, office, medical training. 1.15.5 The system shall allow designating per custom attribute, the source and permitted method of update – synching with external Directory, Import, Operator and/or End-User. 1.15.6 Custom attributes can be used for querying, management, and targeting users. 1.15.7 The system shall support managing organizational structure/hierarchies, including targeting, reporting, and grouping based on hierarchy. 1.15.8 The system shall support exporting recipients’ data, including personal information, target groups membership, and contact information or a subset of these, using CSV files.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.15.9 The system shall show and export for an operator only the users in the allowed targeted user audience. 1.16 Self-Service 1.16.1 The system shall provide a web-based Self Service module to allow end-users to update their own personal information, including custom attributes and contact information (telephone numbers, email addresses, etc.) and other information, all subject to appropriate permission The system shall allow users to select their primary notification attribute. 1.16.2 The system shall provide a web-based Self Service "Inbox" allowing recipients to check for recent alerts. 1.16.3 The system shall allow an administrator to configure what user attributes will show in the Self-Service pages and whether user attributes are read-only or updatable by end users. 1.16.4 The system shall allow an administrator to configure what user contact details will show in the Self-Service pages. 1.16.5 The system shall allow an administrator to configure additional Self-Service pages to address a specific category of user data for self-update; for example, reporting personnel status during emergency situation for personnel alerting. 1.16.6 The Self Service capability shall include positive authentication of the end user via Active Directory, CAC, username/password, or by integrating with Single Sign On system. 1.17 Integration with Personnel Data Sources 1.17.1 The system shall support concurrent integration with multiple sources of user data to create recipient records. Contact and user information can be created via Self Service, integration with Active Directory, Lightweight Directory Access Protocol (LDAP), Human Resource Management Systems (HRMS), CSV files, and other organizational personnel repositories via APIs. The system shall not overwrite information pulled from the Self-Service module. 1.17.2 The system shall support LDAP/Active Directory integration for end-users (recipients), with ability to import organizational hierarchy and distribution lists, as well as per user custom attributes, organizational membership (OU, security groups), and device addresses. 1.17.3 The system shall support concurrent integration with multiple sources of user data to create recipient records.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.17.4 The system shall support periodic and automatic synchronization with multiple data sources, without requiring administrator intervention. 1.17.5 Supported user-directory integrations include: LDAP, Active Directory, HRMS, and others via open APIs. 1.17.6 The system shall support AMC’s transition/migration from the AMC-2K domain to the AFNet domain and new centralized AF Active Directory and Exchange architecture. 1.18 End User Data Reports 1.18.1 The system shall support analysis and estimate of recipients reach coverage by personal delivery devices (such as desktop, phone, email, SMS) by analyzing contact details data in its user repository, to include: 1.18.1.1 The system shall generate reports showing contact details data coverage for all or some of the recipients, using dynamic hierarchical and data queries using a combination of all user attributes. 1.18.1.2 The system shall allow showing lists of personnel who are covered and personnel not covered by contact details data (i.e., missing contact details). 1.18.1.3 The system shall allow selection of delivery devices for coverage analysis. 1.18.2 The system shall support graphical and tabular coverage reports. 1.18.2.1 The system shall allow formatting of coverage reports for printing and export to XLS. 1.18.2.2 The system shall support the ability to send alerts to all end-users (recipients) with missing contact information to remind and request updates with link to Self Service front-end. 1.18.2.3 The system shall support reporting of users based on user attributes. 1.18.2.4 The system shall generate reports showing user attribute data for all or some of the recipients, using dynamic hierarchical and data queries using a combination of all user attributes. 1.18.2.5 The system shall allow drill down to list of personnel with specific value(s). 1.18.2.6 The system shall support graphical and tabular user reports. The system shall allow formatting of user reports for printing and export to XLS.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.18.2.7 The system shall show an operator only the users allowed in the targeted user audience. 1.19 Personnel Alerting 1.19.1 The system shall include personnel data attributes to be used to collect personnel status in emergency situations. 1.19.2 The system shall allow end users to update their personnel alerting status using web-based Self-Service, and inform users to also report status in the Air Force Personnel Accountability and Assessment System. 1.19.3 The system shall allow operators to review and update end-user alerting status using the web based end user management. 1.19.4 The system shall provide reports to operators on personnel status, allowing drill down by organizational hierarchy and distribution lists. 1.20 Operator Access and Management. 1.20.1 The system shall provide web-based, role-based central administration, accessible from multiple networked locations. 1.20.2 The system shall enforce authentication for alert activation, administration and management via username and password, CAC or integration with Single Sign On system. 1.20.3 The operator Password Management shall comply with DoD Password Management Policy. 1.20.4 The system shall support permissions management capabilities to allow only administrators with appropriate privileges to view and/or modify personnel information and contact details, and target sub-set of recipients. 1.20.5 The system shall provide operator permissions and access management tools that limit the rights to alert and manage a specific unit (including its end-users/recipients and all other parameters), or multiple such units. 1.20.6 Role-based permissions for operators including: fully admin, alert activator, user data manager, and more; role definition shall be extensible. 1.20.7 The system shall provide policy management capabilities to support operators, including the ability to define access permissions according to multiple dimensions and access to certain end-users, scenarios.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.20.8. All operator activities shall be centrally audited, including failed logins. As a minimum the audit shall record the following details per action: user-id, object type, what action, source IP. Web based audit report is available for privileged administrators, and can be exported. 1.20.9 The system shall support the specific number of operators and shall allow the operators with administration rights to add, remove, and manage operators’ details and permissions. 1.21 Enterprise Multi-tenancy and Regional / Enterprise Wide Notifications 1.21.1 The system must support deployment with multi-tenants capability – supporting a multi-location organization made up of multiple units (e.g., base, department); for example, the system could be deployed in HQ supporting not only the entire organization as a whole, but also subordinate AMC units (e.g., wings, squadrons) via their own separate virtual system. 1.21.2 The system shall support logical segmentation between multiple organizational units based on permissions and access rights. This separation includes management of administrators/operators, end-users, LDAP/Active Directory integration, organizational hierarchy, distribution lists scenarios, targeting, organizational hierarchies, alerts, system parameters, devices, and telephony systems. 1.21.3 The system shall provide complete access and visibility from HQ into all units of the system to view alert activity, reports and users. 1.21.4 Operator roles and permissions can span across multiple units / tenants, with different roles and permissions per unit/tenant. 1.21.5 The system shall support shared repository of parameters, delivery templates, and audio files for use by all units, allowing centralized management. 1.21.6 The system shall allow “alert cascading” allowing one department (e.g., HQ) to activate alerts to sub-ordinate departments, per-defined setup of relations between departments and HQ in one alert activation. 1.22 Section not used 1.23 Event Monitoring and Alert Triggering. 1.23.1 The system shall have the capability of event monitoring and alert triggering. 1.23.2 The System Integrator shall ensure mandatory integration and interoperability requirements. To avoid stove-piped systems and leverage existing or pending Air Force EMNS capabilities, Vendor should demonstrate or present documented evidence of interoperability and integration with Microsoft OCS collaboration tools and Cisco Voice

FINAL (8 Nov 2010, Updated 25 Aug 11)

over IP capabilities which are currently deployed, or will be deployed on AMC bases. The required mandatory interoperability should be as described below: 1.23.2.1 Microsoft OCS –The vendor must demonstrate the ability to alert to users via OCS Instant Messaging including capturing responses and aggregating these responses into the main tracking reports of the emergency notification system. 1.23.2.2 Cisco VoIP Phones – on most AMC bases where there are Cisco VoIP phones, the interoperability requirement calls for sending audio-video alerts to the displays of these phones, capturing responses and aggregating these responses into the main tracking reports of the emergency notification system. 1.23.3 The system shall support, as an option, to incorporate event monitoring capability to monitor multiple external event sources and sensors and trigger alerts based on matched conditions. 1.23.4 The system shall support integration with physical security devices (chemical sensors, video surveillance, and fire sensors throughout the installation) alerting all recipients or special interest groups based on business rules. 1.23.5 The system shall provide APIs to build monitoring agents that can connect and monitor external event sources, such as databases, content repositories, RSS / Atom feeds, CAP messages etc. 1.23.6 The system shall have mechanisms to avoid duplicate activation of the same alert coming from an external system. 1.23.7 The system shall support two methods for interacting with the monitoring agents, either by 1) listening to events coming from registered agents, or 2) activating and pulling information from the registered agents on a periodic schedule. 1.23.8 The system will allow administrators to define alerting criteria, which, when matched to monitored events, will automatically trigger alerts to the applicable recipient groups. 1.23.9 The system shall include an API to trigger an alert from an external system using a predefined scenario, and/or by specifying alert content, targeting and options on the fly. 1.24 Weather Alerts 1.24.1 The system shall have the capability of providing weather alerts through operator input or automatic inputs. The system shall allow the operator the capability to approve/disapprove message release for a defined period of time. 1.24.2 The system shall support integration with available public weather warning sources and/or with DoD weather services using standard protocols such as CAP and

FINAL (8 Nov 2010, Updated 25 Aug 11)

RSS. The system shall support setting up alerting conditions by administrators with appropriate privileges; alerting conditions shall include: 1.24.2.1 What source to monitor 1.24.2.2 What combination of conditions to watch 1.24.2.3 What geographic area to cover 1.24.2.4 Who to target the alert. 1.25 Continuity of Operations Capability 1.25.1 To address potential scenarios of base evacuation or base communication isolation (network or telephony), the System Integrator shall provide an additional stand-alone mobile alerting capability per base, enabling each AMC installation to initiate telephony, text messaging, and email alerting even during loss of the base’s Command Post, IP network, local base telephony exchange, or prime and failover emergency notification system. This stand-alone, mobile failover alerting capability must: 1.25.1.1 Not rely solely on local government network or telephone systems. 1.25.1.2 Synchronize with AMC’s main notification systems to have available all personnel contact information, emergency scenarios, and other information needed for emergency alerting. 1.25.1.3 Maintain such information (as listed above) in a secure encrypted method. Not use a commercially hosted capability to store sensitive AF information (including personnel content information). 1.26 Notification Subscription 1.26.1 The capability outlined in this section is optional. As such, the Customer does not intend to procure this capability as part of this capabilities document, but does require such capability will be available in the system for subsequent procurement and/or upgrade. 1.26.2 The system shall support, as an option, subscription of users to notifications, allowing mandating, opting-in, opting-out and blocking users and user-groups for delivery of certain categories of notifications or events. 1.26.3 The system shall support central control of subscription business rules per alert category. 1.26.4 Based on the business rules, the system shall allow users to update their subscription profile via the web based Self-Service and must include the Privacy Act statement.

FINAL (8 Nov 2010, Updated 25 Aug 11)

1.26.5 The system shall support personal notifications subscription, allowing end users to create personal subscriptions by designating their own business rules on delivery of notifications and events, via the web based Self Service. 1.27 System Interoperability 1.27.1. The System Integrator will install a system that supports consolidated or integrated Command Posts, by integrating with existing Network Alerting Systems used in AMC Command Posts; specifically the system shall be interoperable with existing AMC ENSs by allowing AMC controllers to target local tenant populace and trigger alerts in the respective EMNS systems. 1.27.2 The System Integrator shall work with the Configuration Management team and the Global Air Transportation Execution System (GATES) operational team when necessary to update the GATES web page. 1.28 Security and Regulations Compliance Requirements 1.28.1 DoD Information Assurance Certification/Accreditation Process (DIACAP). The system must be designed for optimal DIACAP compliance. Reference DoD Instructions 8510.01, The Defense Information Assurance Certification and Accreditation Process (DIACAP) and DoDI 8500.02, Information Assurance (IA) Implementation, for the specific security controls/ requirements mandated by DoD policy. Additionally, Air Force Instructions 33-200, Information Assurance (IA), and 33-210, Air Force Certification and Accreditation Process (AFCAP) provide additional AF-level guidance and clarification for AF-specific implementations of DoD processes and security controls/requirements. 1.28.2 DISA Secure Technical Implementation Guides (STIGs). The System Integrator shall provide COTS net-centric system designed in accordance with DISA STIG specifications. See http://iase.disa.mil/stigs/index.html for more information. 1.28.2 Common Access Card (CAC). The System Integrator shall provide a COTS netcentric EMNS that fully meets CAC compliance requirements described in Service Manual, “Identification and Authentication,” and consistent with DoD Instruction 8520.2, Public Key Infrastructure (PKI) and Public Key Enabling. 1.28.3 Section 508 of the Rehabilitation Act Compliance. The System Integrator shall demonstrate visual alerts delivered to end users via their computer desktop/laptop workstations can be accessed using assistive technology such as Job Access with Speech (JAWS) software. 1.28.4 Unified Facilities Criteria (UFC) 4-021-01 and 4-010-10 Compliance. The System Integrator shall provide a COTS net-centric system that meets UFC 4-010-10 (DoD Minimum Antiterrorism Standards for Buildings) and UFC 4-021-01 (Design and O&M:

FINAL (8 Nov 2010, Updated 25 Aug 11)

Mass Notification Systems) criteria and compliance; the system must comply with NCAS requirements as formulated in Appendix C of April 2008 UFC 4-021-01. 1.29 Potential Use of Current AF Net-Centric AtHoc MNS Licenses 1.29.1 The provider will include the use of other AF net-centric licenses where possible as part of their proposal to provide this capability to AMC. 1.30. Proposal Requirement 1.30.1 Provider will include initial installation costs at the AMC installations, broke out by installation and will provide an estimate for three years sustainment, broken out by year.