Automated Secure Alarm Protocol (ASAP)
CSAA International, the Association of Public Safety Communications Officials (APCO) and the National Law Enforcement Telecommunications System (Nlets) have been working to improve the exchange of alarm information to public safety dispatch centers. The result of this effort is the ground-breaking Automated Secure Alarm Protocol (ASAP) service from CSAA.
The ASAP service provides a uniform method to deliver American National Standards Institute (ANSI) standard alarm exchange messages to a public safety dispatch center, typically known as a Public Safety Answering Point (PSAP).
The following interview with Glenn Schroeder, co-chair of the ASAP Technical Committee and chief technology officer with Security Network of America, helps to clarify some of the more technical components of the ASAP service. Schroeder, along with ASAP Technical Committee Co-Chair Tony Mucci (Tyco Integrated Security) and Robert Turner (CommSys), have been working tirelessly for more than two years on the vast technical challenges of implementing the evolutionary ASAP program.
Q: What is the ANSI Alarm Exchange Standard?
A: The ANSI standard describes an XML data exchange between the central station’s automation platform and the dispatch center’s computer-aided dispatch (CAD) system. The CSAA-APCO ANSI 2.101.1-2008 standard is the primary document. The document describes common data elements, structure, and process flow to electronically transmit alarm events and updates from an alarm monitoring company to a dispatch center’s CAD system and back.
Working with APCO, CSAA modified the 2008 standard and is working through the ANSI standard update process. These modifications have allowed the ANSI Standard to better support new transport methods such as the ASAP Service.
Q: How are alarm signals delivered?
A: Since the ANSI standard does not define the actual transport method, CSAA needed to develop its own web service to serve as a transport method using the ANSI Alarm Exchange.
With more than 6,500 PSAPs across the United States and hundreds of central stations, a direct connection between each central station into every PSAP is clearly neither scalable nor cost effective. Instead, an alternative was identified using the nation’s Criminal Justice Information Systems (CJIS). This secure network is used by law enforcement for inter-agency communication and for looking up wanted persons, vehicles and property.
Q: How are the CJIS networks used?
A: The CJIS network infrastructure connects about 80% of the PSAPs, specifically those with a law enforcement responsibility. The CJIS network infrastructure is a crucial component of law enforcement in the country. Each state has its own CJIS system and network that connects with local law enforcement agencies and related dispatch centers.
At the top levels of the CJIS infrastructure are the FBI’s National Crime Information Center (NCIC) and Nlets. These networks/systems interconnect with each of the state-level CJIS systems. This allows a connected system to communicate electronically with almost any law enforcement agency in the United States, and potentially Canada. By connecting CSAA’s web service to Nlets, a single point or “gateway” facilitates delivery of messages to PSAPs via the state and territorial CJIS networks connected to the Nlets network.
CSAA is a Strategic Partner Organization (SPO) of Nlets, allowing the CSAA to use Nlets’ network connections with the state CJIS systems for the express purpose of delivering and receiving alarm system activation messages to and from PSAPs.
Q: We’ve seen all sorts of references to ASAP, but how does it really work?
A: CSAA strived to use common industry technologies to implement the ASAP service while creating a technical solution that is capable of scaling and evolving to support the needs of the ASAP subscriber base.
The ASAP service is implemented via a custom-developed web services message broker. The message broker is a gateway, router, filter and security enforcer between the central station’s automation platform and a dispatch center’s CAD system. At its core, the ASAP message broker, in conjunction with the networks to which it connects, is a bridge between the environments of central station automation platforms and the PSAP’s CAD system.
The ASAP service is responsible for aggregating, accepting and processing alarm messages coming from participating central stations. To connect with the message broker and to use the ASAP service, central stations are required to use a CSAA-approved alarm automation software provider and to implement a web service listener to receive responses.
Q: What kind of traffic does the message broker handle?
A: The conduit through which all traffic from a central station accesses the message broker is a Virtual Private Network (VPN) connection implemented over the Internet between the central station and the Nlets data center. Currently, CSAA ships a preconfigured Cisco ASA 5505 VPN router/firewall that remains under the ASAP service’s control.
Two separate communication paths between the Message Broker and the PSAP are established. One path transmits to the message broker; the other path receives from the message broker. In HTTP terms, the information will only be received as the result of a POST operation to the web server at the message broker or the alarm automation software at the central station.
The central station automation platform sends messages to the message broker. The message broker validates the message structure and destination PSAP, and sends the message to the Nlets Justice Information Network (NJIN) system. The NJIN system then routes the message to the proper state CJIS system. Finally, the state CJIS system sends messages to the connected local CAD system.
For messages from the PSAP to the central station, the process is reversed.
The ASAP service uses web services via a SOAP envelope. The ASAP service has developed a Web Services Definition Language (WSDL) for communications with the ASAP message broker.
Q: What central station automation software is approved to work with ASAP?
A: All information necessary for central station automation vendors to develop and support their implementation of communication with the ASAP service is available in the CSAA’s Interfacing Technical Document (ITD). This document and the WSDL are considered to be sensitive but unclassified, and can be only released under a Non-Disclosure Agreement between CSAA and a company with employees having a need for this information.
UTC/MAS and DICE currently have central stations in full production with significant traffic using the ASAP service. BOLD has developed, tested and placed into production its solution and is ready for full traffic. Other automation vendors have received the ITD, and are developing their own solutions. We expect to test and verify solutions from other automation platform providers in the coming months as they complete their software development cycles.
Check with your automation provider to see where it is in its development. If you write your own central station software and it is listed to comply with UL1981 requirements, you should initiate a conversation with the ASAP Technical Committee and request a copy of CSAA’s ITD. Here are some additional references and documents that you may require:
CSAA-APCO ANSI 2.101.1-2008 Standard.
Addendum and updates to the CSAA-APCO ANSI 2.101.1-2008 Standard, including Schema 3.3, dated 12/5/11 and Schema 3.3 update, dated 2/1/12.
ITD, Addendum 1.
Relevant sections of CSAA’s Security Policy, which has been approved by Nlets.
Q: Can we connect to the ASAP service and start sending signals right away for all of our subscribers?
A: Unfortunately, the ASAP service doesn’t work that way. A central station must connect to the ASAP service; however, a connection does not allow the central station to pass traffic to a PSAP. The central station must be in contact with a particular PSAP to coordinate the exchange of alarm information.
First, any PSAP that wants to accept ASAP messages will need to upgrade its CAD system. Several CAD providers already have solutions available, and many are implementing their solutions per the requests of the PSAPs.
Second, the central station will need to work with the PSAP to rectify subscriber street addressing issues. The street address of the subscribers for the automation system and the PSAP CAD system must be identical. Otherwise, the exchange will be rejected.
Once the PSAP is comfortable with the central station and its address data, the PSAP must notify the ASAP Service that it is ready to begin accepting traffic from a particular central station. The process must be followed for each PSAP with which the central station wishes to commun
Q: What happens if a signal does not get delivered to the PSAP?
A: The central station needs to revert to its normal process of transferring the call to the PSAP via a voice conversation. The central station needs to revert to the old processes if the automation software is unable to transmit the call to the PSAP for any reason, reject or “no response” time out.
Q: Why are there security requirements for the ASAP service?
A: The nation’s CJIS networks are a critical infrastructure supporting law enforcement and public safety. The FBI is charged with the responsibility for maintaining the security and integrity of these networks.
Policy mechanisms dictate the security requirements to the state CJIS networks and Nlets. In turn, Nlets enforces applicable security requirements to its strategic partners, such as CSAA. As part of becoming a strategic partner of Nlets, CSAA developed a comprehensive security policy with requirements for the ASAP service subscribers and the automation software providers. The purpose of these requirements is to ensure the integrity and security of the central station’s automation platform and the network connection to the ASAP service.
Q: Can we have multiple connections to the ASAP service?
A: Generally speaking, no. Currently, the ASAP service is defined to have a single connection to a single central station location. The central station will need to develop a way to aggregate multiple alarm messages from its automation systems and conversely distribute PSAP responses to the automation systems from a single stream. If your company’s specific needs require connections to multiple locations, you will need to work with the CSAA’s Technical Committee for possible solutions.
Q: Can we use our own network hardware to establish the VPN connection?
A: Maybe. The ASAP service requires the use of a Cisco ASA 5505 VPN router/firewall at the central station. If your company can demonstrate that it has the required expertise to configure and maintain the specific implementation of this device, CSAA’s Technical Committee will consider your request. Staff certifications (minimum, CCNA) and additional security clearance will be required.
Q: Will we have the ability to pass a video feed from the subscriber premise to public safety via the ASAP service?
A: Yes and no. The ASAP service does not understand nor is it capable of passing multi-media information feeds such as video and audio. However, the revised ANSI standard does provide a URL field in order to have a method for the public safety user to connect to an external web service to access a video or other multimedia feed.