1360407-19 - Next Generation 9-1-1 Solution

Request for Proposal (RFP) # 1360407-19
TPS is accepting proposals for the provision of an end-to-end, turn-key Next Generation 9-1-1 (NG9-1-1) solution for our 9-1-1 Command Centre.
 
Submission Requirements
Proposals must be submitted through the MERX Electronic Bid Submission (“EBS”) System (https://www.merx.com/).
 
For assistance using MERX, please contact MERX directly at 1-800-964-MERX or visit the MERX website at www.merx.com.  
 
Proponents are to submit their proposal through the MERX EBS System prior to 1:00:00 P.M. local time on Friday, January 24, 2020.
 
 
Objectives
TPS’s primary objective with this initiative is to acquire a new highly secure, IP based NG9-1-1 solution in a geo-diverse design configuration.
The new solution should be able to accommodate SIP voice calls, teleconferencing, as well as RTT (Real Time Texting – RTT) at the time of the bid submission; and any future IP technologies, such as instant messaging, sending video or pictures, and other such technologies or applications as they are made available and become part of standards. 
 
Mandatory Requirements
Network Design

• The proposed solution must be an IP-based solution and must comply with all current NENA i3 standards at the time of the issuance of the Notice of Award.
• The proposed solution must support Layer 3 network connectivity across the WAN to be in compliance with TPS infrastructure standards.
• The proposed solution must be built on an open standards platform for interoperability with other NENA-compliant systems and ESInet connectivity.
• The proposed solution must be SIP Compliant as defined in NENA 08-003 (https://www.nena.org/page/i3_Stage3) for ESInet connectivity.
• The proposed solution must be 100 percent on premise solution i.e. all components involved in the solution must be on premise.
• If the solution includes cloud based licenses it must continue to function in full if connectivity to a cloud based component is lost for an extended period of time.
• The proposed solution must integrate with the existing TPS infrastructure
• The proposed solution must accept NENA i3 VoIP calls natively i.e. the new solution must accept SIP calls as defined by NENA standards. 
• The proposed solution must provide analog circuits for ring down phone connectivity. 
• The proposed solution must provide TDD and TTY (as per AODA) support until the service is decommissioned or phased out.
• The proposed solution must provide the capability of sending SMS/text messages to cell phones.
• The proposed solution must have the capability of storing and sending a minimum of ten canned SMS/text messages to cell phones.
• The proposed solution must provide SIP as primary and QSIG as secondary service for administrative lines use, transfers and or call backs.
• The proposed solution must provide “No Single Point of Failure” architecture, i.e. the new solution must provide High Availability with redundant server level components (HA; hardware and software) on each site and between sites.
• The proposed solution must provide no system downtime or loss of call processing functionality when there is a hardware or software failure and the system is failed over to either redundant server on-site or at the backup site.
• The proposed solution must provide active-active architecture.
• The proposed solution must provide automatic real-time synchronization of primary and secondary server databases.
• The proposed solution must provide automatic and seamless failover without any manual intervention in the event of a hardware or software component failure.
• The proposed solution must support and process audio signal entering the CPE (Customer Premise Equipment) to use G.711 CODEC (as per NENA) for maximum call reliability.
• The proponent must include transcoders (if already not included in the PBX for transcoding to G.711 CODEC) as part of the solution.
• The proposed solution must support Dual stack IPv4 and IPv6 capabilities for ESInet connectivity.
• The proposed solution must include BCF (Border Control Function) components like SBC, etc. for ESInet connectivity.
• The proponent must provide BCF (Border Control Function) Firewall configuration to TPS for ESInet connectivity.
• The proposed solution must connect to external NTP clock source, Bell provided NTP network time receiver on ESInet as mandated by CRTC - in order to ensure consistency of timestamps added to event records and MIS reports from all PSAP equipment.
• The proponent must provide hardware for the new PBXs.
• The proponent must provide analog cards for ring down phones with new PBX hardware.
• The proponent must provide a minimum of 12 analog ports per PBX with the ability to add additional ports or analog cards as needed.  
• The proponent must provide software and required licenses for the new solution.

• The proposed solution must support Active Directory (AD) integration.
• The proposed solution must support Single Sign-On (SSO) capability for agents as per NENA requirement.
• The proposed solution must be secure, in compliance with NENA NG-SEC 75-001 (https://www.911.gov/pdf/NENA_Security_Next_Generation_911_Standard_2010.pdf).

• The proposed solution must be in compliance with TPS security standards
• The proposed solution must encrypt authentication credentials when stored on a computer.
• The proposed solution must use encryption algorithm certified by the NIST FIPS 140 certification, currently AES.
• The proposed solution must have the capability to support two-factor authentication for both servers and clients.
• The proposed solution must use industry standard cryptographic algorithms and standard modes of operations for cryptographic installations.
• The proposed solution Symmetric keys must be at least 112 bits in length and Asymmetric keys must be at least 1024 bits in length.
• The proposed solution must display authentication credentials in an obscured format when entered on computer screens.
• The proposed solution must require a password for all user accounts.
• The proposed solution must lock out users after no more than 5 invalid sign-on attempts.

• The proposed solution must not reside or allow data to flow outside Canada as mandated by CRTC.
• The proponent must have provided 3+ years of 911 Call Handling system support and services within the last 5 years.
• The proponent and their staff must be legally authorized to work in Canada.  
• The proposed solution must have fully operational Voice call functionality at the time of the proposal submission of this RFP. 
• The proposed solution must have fully operational Real Time Text call (RTT) capability at the time of the proposal submission of this RFP. 
• The proposed solution must have 99.999% availability or higher as per NENA i3 defined standards.
• The proposed solution must be capable of handling of minimum of 2 million voice calls per year.
• The proposed solution must preserve active calls in the event of system failures. 
• The proposed solution must provide an off-hook detect signal.
• The proposed solution must provide the capability to place a call on exclusive hold.
• The proposed solution must provide supervisor assistance capability.
• The proposed solution must provide silent monitoring capability. 
• The proposed solution must provide supervisor barge-in capability. 
• The proposed solution must provide two headset plug-ins to support each Call Taker desk.
• The proposed solution must provide two adapters to connect receivers for each Dispatcher desk.
• The proposed solution must integrate with Hexagon CAD using IP trunks.
• The proposed solution must support Windows 10 64 bit operating systems on CAD workstations.
• The proposed solution must support Microsoft Internet Explorer Version 11.0 web browser on CAD workstations.
• The proposed solution must support Google Chrome Version 77/78 web browser on CAD workstations.
• The proposed solution must support Microsoft Edge Version 40 web browser on CAD workstations.
• The proposed solution must support Microsoft Edge HTML Version 15 web browser on CAD workstations.
• The proposed solution must provide Call Detail Records (CDR) for all calls.
• The proposed solution must store Call Detail Records (CDR) and all available information pertaining to each 911 call on the application/telephony server.
• The proponent must be committed to have their solution compatible with Bell UNI Specifications, within CRTC mandated timeline.
• The proposed solution must have an overflow routing capability.

• The proposed contact centre solution must include an ACD queuing algorithm system for voice 911 calls.
• The proposed contact centre solution must include an ACD queuing algorithm system for voice 911 calls with Longest Idle feature.
• The proposed contact centre solution must include an ACD queuing algorithm system for Text-to-911 calls.
• The proposed contact centre solution must include an ACD queuing algorithm system for Text-to-911 calls with Longest Idle feature.
• The proposed contact centre solution must include an ACD queuing algorithm system for administrative calls.
• The proposed contact centre solution must include an ACD queuing algorithm system for administrative calls with Longest Idle feature.
• The proposed contact centre solution must provide Call Taker capability to change their state from idle, not ready, busy, etc. to ready to receive an ACD call.
• The proposed contact centre solution must provide skills-based call routing to direct calls to available Call Takers with specific skills.
• The proposed contact centre solution must provide priority-based queuing to direct 911 calls to high priority queue.
• The proposed solution must provide configurable reason codes for group specific customizations, i.e. group specific reason codes for Call Takers and Dispatchers.
• The proposed solution must allow administrator to add/remove skills of a Call Taker or Dispatcher.
• The proposed solution must allow administrator to customize/modify Call Taker user interface.

• The proposed solution must provide customizable wallboard/dashboard.
• The proposed solution must be capable of supporting the wallboard/dashboard on an office monitor.
• The proposed solution must be capable of supporting the wallboard/dashboard on a large screen such as an LCD, LED or plasma television panel.
• The dashboard/wallboard function must be capable of displaying the queue data from multiple sources such as CAD, ACD, etc.

• The real-time call display must show call data for 911 calls.
• The real-time call display must show call data for Non-Emergency calls.
• The real-time call display must show call data for Administrative calls.
• The proposed solution must provide real-time call information on number of calls connected for 911 calls. 
• The proposed solution must provide real-time call information on number of calls in queue for 911 calls. 
• The proposed solution must provide real-time call information on number of calls abandoned for 911 calls. 
• The proposed solution must provide real-time call information on number of calls ringing for non-emergency calls.
• The proposed solution must provide real-time call information on number of calls connected for non-emergency calls.
• The proposed solution must provide real-time call information on number of calls in queue for non-emergency calls.
• The proposed solution must provide real-time call information on number of calls abandoned for non-emergency calls.
• The proposed solution must provide real-time call information on number of calls connected for administrative calls.
• The proposed solution must provide real-time call information on number of calls in queue for administrative calls.
• The proposed solution must provide real-time call information on number of calls abandoned for administrative calls.
• The proposed solution must provide real-time call information on number of inbound calls ringing for each group of which a logged-on user is a member.
• The proposed solution must provide real-time call information on number of users ready to receive a call for each group of which a logged-on user is a member.
• The proposed solution must provide real-time call information on number of users not ready to receive a call for each group of which a logged-on user is a member.
• The proposed solution must provide real-time call information on number of users on a call for each group of which a logged-on user is a member.
• The proposed solution must provide real-time call information on Position the user is working for each logged-on user.
• The real-time call display must show data for each user group, i.e. Call Takers and Dispatchers.
• The real-time call display must show data for each logged-on user.

• The proposed solution must provide a reporting system with real-time and historical information.
• The proposed solution must offer a customizable reporting system so that generating of reports for varying time periods can be selected.
• The proposed solution must provide "Agent Not Ready by Reason Code" historical agent performance report.
• The proposed solution must provide "Average Calls per Hour" historical agent performance report.
• The proposed solution must provide "Agent by Application Skillset" historical agent performance report.
• The proposed solution must provide "Agent by Skillset" historical agent performance report.
• The proposed solution must provide "Agent by DN (inbound/outbound calling)" historical agent performance report.
• The proposed solution must provide "Agent Efficiency by Skillset" historical agent performance report.
• The proposed solution must provide "Agent Login/Logout" historical agent performance report.
• The proposed solution must provide "Agent Performance" historical agent performance report.
• The proposed solution must provide complete call records of all Emergency and Non-emergency calls, i.e. records from the time call enters the PBX, goes through the script until the end of the call by Call Taker.
• The proposed solution must provide "Application by Skillset Report" historical report.
• The proposed solution must provide "Application Delay before Abandoned" historical report.
• The proposed solution must provide "Application Delay before Answer" historical report.
• The proposed solution must provide "Application Performance" historical report.
• The proposed solution must provide "Directory Number Statistics" historical report.
• The proposed solution must provide "Route Performance" historical report.
• The proposed solution must provide "Skillset Performance" historical report.
• The proposed solution must provide "Skillset by Application" historical report.
• The proposed solution must provide "Directory Number Daily" historical report.
• The proposed solution must provide "CWW (Monthly) Agent Report by Team (supervisor)" historical report.
• The proposed solution must provide "CWW (Monthly) Agent Report by Agent" historical report.
• The proposed solution must provide role based access to GUI reporting interface.
• The proposed solution must integrate with NICE VLS, version 7 onwards.
• The proposed solution must record all calls simultaneously (active and parallel architecture setup) to both primary and backup NICE VLS system. 
• The proposed solution must provide ANI/ALI metadata for NICE VLS.
• The proposed solution must allow all call related information to be saved in electronic format, at minimum and including .xls, .PDF, and .csv.
• The proposed solution must be capable of capturing and storing ANI / ALI call data for each 911 call.
• The proposed solution must provide the capability to store and search Originating Phone Number (ANI) during the data retention period.
• The proposed solution must provide the capability to store and search Address or Coordinate (ALI) during the data retention period.
• The proposed solution must provide the capability to store and search Caller Name during the data retention period.
• The proposed solution must provide the capability to store and search ANI / ALI Time of Initiation during the data retention period.
• The proposed solution must provide the capability to search and store ANI / ALI Time of Pickup during the data retention period.
• The proposed solution must provide the capability to store and search ANI / ALI Time of Disconnect during the data retention period.
• The proposed solution must provide the capability to search and store ANI / ALI Date during the data retention period.
• The proposed solution must provide the capability to store and search ESN (Emergency Services Number) during the data retention period.
• The proposed solution must provide the capability to store and search Class of Service during the data retention period.
• The proposed solution must provide the capability to store and search LEC (Local Exchange Carrier) during the data retention period.
• The proposed solution must have the capability to limit download of local recordings by Call Takers and Dispatchers, i.e. only users with permissions will be able to download recordings.

• The proponent must have 24x7x365 real time remote system monitoring via secure communication tunnel.
• The proponent’s NOC (Network Operations Centre) for remote monitoring must be within Canada.
• The proposed solution must allow SNMP monitoring of all the components of the proposed solution using TPS’s enterprise network and storage monitoring (e.g. network connectivity, CPU health, memory usage, disk usage, etc.) software SolarWinds.
• The proposed solution must be capable of self-monitoring vital processes and sending alarms in the event of an alarm condition.
• In the event of a self-monitored system alarm, the proposed solution must distribute an e-mail, providing brief description of the alarm condition to individuals or email addresses identified by TPS.
• In the event of a self-monitored system or network down alarm, the proposed solution or proponent must notify TPS personnel via phone call and provide brief description of the alarm condition.
• The proposed solution must provide a minimum of two (2) categories of alarms (non-critical and critical) depending upon the nature of the event.

• All critical system files such as Maintenance Logs, Statistics, Call Records and stored ALI Information, etc. must be saved daily to an external storage device provided by TPS.
• All critical system configuration files must be saved weekly to an external storage device provided by TPS.
• The proposed solution must have the capability to restore the system to last known good working configuration by utilizing system configuration backup.

• Priority 1 - High: Entire system is unavailable. Both primary and the redundant back-up systems are affected. TPS is expecting immediate response and direct transfer to Level-3 support to begin troubleshooting; workaround must be implemented within 1 hour; the issue must be resolved within 4 hours. If it is deemed necessary that a technician is needed on-site, the technician must be on-site within 2 hours. The Level-3 support must provide constant troubleshooting updates to TPS Telecom personnel until the issue is resolved.    

• Priority 2 - Medium: System still operational but with restricted capability. TPS is expecting response time of under 1 hour; workaround must be implemented within 2 hours; the issue must be resolved within 6 hours. If it is deemed necessary that a technician is needed on-site, the technician must be on-site within 4 hours. The support technician must provide constant troubleshooting updates to TPS supervisor until the issue is resolved.

• Priority 3 - Low: System still operational with minimum effect on capability. TPS is expecting response time of 2 hours; workaround must be implemented within 4 hours; the issue must be resolved within 2 business days. If it is deemed necessary that a technician is needed on-site, the technician must be on-site within 1 day. The support technician must provide constant troubleshooting updates to TPS supervisor until the issue is resolved.
• TPS must be able to change or dictate the priority level of problem based on urgency.

• The proponent warrants the full solution for a period of 12 months after the final, TPS signed-off implementation date. 

• The solution (including hardware) must be supported and maintained by the vendor for the duration of the contract term.
• All logs must be human readable.
• The proponent must provide the operational manuals, system manuals (e.g. runbooks), and schematics for the proposed solution as part of the implementation.

• The proponent must include a comprehensive System Administration training plan. The Advanced technical training (i.e. advanced engineer level including basic troubleshooting) must be provided to TPS support staff responsible for maintenance and support of the new system.
• The proponent must include a comprehensive User Administration training plan for training Administrators within Communication Services (COM) Unit.
• The proponent must include a comprehensive Reporting Administration training plan for training Reporting users within Communication Services (COM) Unit.
• The proponent must include a comprehensive Operational training plan for training Supervisors, Call Takers and Dispatchers within Communication Services (COM) Unit who in turn will train other TPS Call Takers and Dispatchers (as required).
• The proponent must provide training material and video recordings of all the trainings conducted at TPS for future training needs.  
• All trainings must be conducted before cut-over to new solution.
• The proponent must include a customized training plan for various groups within TPS as per TPS requirements.

• The proposed solution must be scalable to accommodate growth in number of Call Taker positions from 103 to 150 without the need to upgrade the system.
• The proposed solution must be able to accommodate unplanned spikes (at least 4,000 in under 1 hour) in call volume generated by extreme/unplanned events in the City of Toronto. Historically TPS has seen an influx of additional 1300-1800 calls under 1 hour caused by extreme/unplanned events.