7 min read

Migrating to the Cloud: The Journey Has Begun

Digital transformation has reached the public safety market. Following in the footsteps of the enterprise and telecommunication domains, the shift from analog lines to SIP-based (Session Initiation Protocol) i3 networks for the distribution of emergency calls has enabled the introduction of new technologies and new ways of operating the public safety answering point (PSAP). 

Connectivity to the Internet has opened access to a range of over-the-top solutions, from localization services to multimedia solutions. This same connectivity also presents new infrastructure solutions that can greatly simplify the makeup of a modern PSAP. And simplification is needed.  

From the initial days of basic analog phone lines ringing at a desk phone and radios to reach out to the first responders, 911 centers have evolved significantly: from business type PBXs (private branch exchanges), to more intelligent PC “softphones” (applications that let users make calls via the internet) that presented additional data and much richer functionality, to the addition of CAD systems for dispatch, map systems for geo-positioning, reporting systems for performance tracking, and recording systems for forensic purposes. 

The result is that today’s PSAPs have become mini data centers. The PSAP back room is filled with rack mount servers and networking equipment. This equipment needs to be deployed, powered, cooled, maintained, upgraded, backed up, and managed. This is not the core of law enforcement but comprises a significant portion of PSAP administration. 

Beyond the distraction from its core objectives, the presence of this equipment presents a significant impediment to the modernization of the PSAP. The introduction of new features and functionality that requires hardware upgrades is delayed until the next hardware refresh cycle which is often years away. 

Digital transformation promises to alleviate this burden from the PSAPs by migrating these backroom functions to the cloud. Many PSAPs are tempted to rush to this transformation, and rightfully so, however, one must learn the lessons of the enterprise digital transformation.

•    A report from Cloud Security Alliance suggests that 90% of CIOs have experienced failed or disrupted data migration projects—mostly due to the complexity of moving from on-premises environments to the cloud. Only 25% of those surveyed in the same study met their deadlines for migrations, with the average project taking 12 months.
•    A 2019 study from Fortinet found that 74% of companies have moved application back to on-premises from the cloud—repatriating them—after failing to achieve the anticipated returns.

These are staggering numbers. When we dig deeper into the cause of many of these setbacks, a common theme is a misunderstanding of the interactions between applications and the impact of network delays on the end-user experience. 

That is to say, the interfaces between applications are not well understood and the shift to the cloud breaks these dependencies in unexpected ways. This concern is even more striking as the evolution of the interfaces for the typical PSAP application has been very uneven and the real-time nature of voice communications along with its criticality to PSAP operations makes the shift from dedicated to shared compute a risky proposition. 

The evolution of the interfaces for the typical PSAP application has been very uneven and the real-time nature of voice communications along with its criticality to PSAP operations makes the shift from dedicated to shared compute a risky proposition.

That is one of the core reasons why we at Intrado have been promoting a hybrid and phased approach to this transformation, leveraging a mix of public cloud where it makes sense, private data centers for real-time functions and local edge compute for interface compatibility. All with the end goal to ensure business continuity and achieve PSAP simplification. 

Let’s look at these interfaces in a bit more detail as we break down the key interactions of the applications involved in a 911 call. 

The call handling platform is often at the heart of PSAP operations. It receives calls from emergency networks as well as from regular phone lines referred to as administrative lines.  

Emergency networks come in the following two major flavors: 

•    Legacy E911
Voice channels carried over T1 trunks (a point to point  connection) into the PSAP.  Referred to as CAMA (Centralized Automatic Message Accounting) lines these trunks are accompanied by a serial link (RS-232) that is used for the purposes of Automatic Location Identification (ALI) queries. This serial link is used to identify the address of the incoming 911 call. 

•    Next Generation 911 
Also known as ESINet or i3 networks, these are IP-based Session Initiated Protocol (SIP) trunks that are carried over IP transport. This SIP-based interface brings in the ability to carry more than just voice traffic. Real-time text, SMS and video calls are also supported over these interfaces. These networks also support IP-based location services that are queried using modern hypertext protocol used by today’s modern browsers. 

Administrative lines are used for non-emergency calls that also end up being routed to the PSAP. They are used for things like towing requests or for PSAP-to-PSAP communications.  They are also used when calling back emergency callers (although newer i3 networks allow such return calls to be done over the NG911 lines). These come in three flavors: analog lines, ISDN lines and SIP trunks.  

Beyond these telephony interfaces, the call handling system also needs to interface with the following systems: 

•    Mapping systems: 
Used to display the call location on a map for the call taker, these systems typically interface over IP networks to receive location information from the call handling platform. Being vendor-specific, these interfaces are often proprietary.

•    Computer Aided Dispatch (CAD) systems: 
These systems are responsible for dispatching first responders to the caller’s location. This information is available from the call handling system and NENA has standardized an interface for this purpose:  a serial-based interface over RS-232 often referred to as CAD out.  

•    Recording systems: 
Used as forensic evidence, 911 calls are recorded by the PSAPs.  Recorders are typically deployed at the PSAP and capture two sources of data: 
o    Call Detail Record (CDR) information
Made available over a serial RS-232 port 
o    Packet capture of the local area network
To capture Real-time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) packets of the voice/text/video conversations at the PSAP

•    Radio systems: 
o    The call taker often plays the role of the dispatcher and has access to radio equipment to be able to contact first responders
o    This radio interface is typically done via analog lines linked back to a radio at each call-taker position 

•    Reporting systems:
o    Used during calls to present a dashboard view of current call taker and call queue states at the PSAP. This information is provided using a vendor-specific, IP-based interface. 
o    Used after calls to calculate individual call metrics. The source of this data is the CDR which is available over a serial interface. 

As we can see from this list, there are several interfaces to consider when moving any of these applications outside the PSAP. Furthermore, many of these interfaces are short reach, specifically the ALI, CAD and CDR serial interfaces. These interfaces were built for local deployment, so careful consideration must be taken for their transition. 

Intrado has taken the approach to provide local edge computing  for these short reach interfaces.  CDR data can be carried over IP by our Remote Data Distribution Module (RDDM), and local CAD systems are supported by our CAD Router component. The ALI interface is being phased away with the transition to i3. 
The development and availability of these modules have enabled Intrado to recommend the following scenario for migrating applications outside the PSAP. 

Reporting 

Our ECATS reporting solution is hosted in a mix of private and public cloud data centers throughout North America. It has few interfaces to consider and can tolerate network latency making it an ideal application to migrate. 
With its input interface being based on CDR information, the RDDM edge compute forwards the information to the cloud and allows PSAPs to remove any reporting servers from their PSAP environment. With relatively few interfaces to consider and good tolerance for network latency, this application is a good candidate. 

Mapping 

Next on the list are mapping applications. The Intrado Spatial Command and Control platform provides a geographic view of the call location and provides additional data elements such as telematics and caller health information. Deployed in public cloud infrastructure, this frees up the PSAP from local map servers and the overhead of map updates that are all included as part of the Spatial Command and Control service. 

Call Handling backroom

The transition from legacy to i3 based emergency networks allows the Intrado VIPER® call handling system to be moved out of PSAP.  Built for scale and fully IP-based, this mission-critical and latency-sensitive application is available as a service from Intrado data centers.  
Redundant network links are used to ensure minimal packet loss and latency, freeing up the PSAP from the bulk of the call handling equipment. 

Call Handling network

Once legacy E911 networks are decommissioned, i3 connectivity can be moved directly to Intrado data centers. Cloud-based PBX services can be used to replace the local administrative lines further freeing up the telecommunications clutter at the PSAP. 

Call Handling front-room

The next step is to convert call handling positions to web-based technologies with Power 911® Web, the Intrado browser-based call handling softphone. No more position-by-position upgrades—web servers hosted by Intrado will fully manage the experience with centralized upgrades ensuring PSAPs are always at the latest release. 

Recording

As mentioned previously, recording systems use very localized interfaces for recording. CDR is used for metadata and switch span ports or analog interfaces are used to capture the voice traffic. The span port technique is very localized and requires a span port on every subnet. This has led to the introduction of the concepts of position-side and trunk-side recording, with PSAPs using both to ensure all voice traffic is recorded. 

This proves to be very difficult for mobile call takers that are used for surge or backup purposes. Being off-site, the recording of their conversations can be missed if they connect to a network where no span port is present. 

The NENA i3 specification has addressed this and recommends that recorders shift to SIPREC (Session Recording Protocol) based technologies for the recording of the RTP media streams and i3 log events for metadata information. These protocols function over IP networks, allowing for the remote deployment of recording solutions. 

Radio Solutions 

Call takers often fulfill the role of dispatchers with dual-mode headsets that allow them to switch from caller to radio with the flick of a switch. This mode of operation can continue to be supported but ties the call taker down to the location of the radio.  

Enabling call taker mobility requires a different approach for access to dispatchers. Push-to-talk functionality such as that supported by AT&T FirstNet can provide this mobility with built-in applications to reach first responders from any location.   

CAD Systems

Dispatcher mobility cannot be achieved if the CAD remains at the PSAP. To support this transition, NENA has been working on the Emergency Incident Data Object (EIDO) specification to replace the decades-old, serial-based interface. The upcoming EIDO conveyance specification promises and IP-based subscription mechanism into the call handling systems that will allow CAD systems to be deployed outside the PSAP.  In the meantime, Intrado supports the CAD router module that acts at the PSAP edge to provide CAD systems with the serial interface they require. 

Intrado’s tenured history in the PSAP gives it a unique perspective into the operational impacts of migrating call handling systems.  Using our balanced approach of public cloud, private data centers and edge compute along with the rigorous interface management strategy described above, PSAPs can mitigate the inherent risk in cloud migration.  

As noted by Gartner, ”A plan to shut down the data center is not a cloud strategy”.  A cloud strategy is the enabler to achieve your operational goals in a pragmatic way that maintains the high standard of operational availability that PSAPs and the public have come to depend on.  

 

To learn more about the challenges PSAPs face and the critical need for resilience and reliability in networks and call-routing, watch episode 1 of our podcast: Intrado is Bringing Life and Safety to the Cloud.

A New Day at Intrado

A New Day at Intrado

The State of Public Safety from Intrado CEO, Jeff Robertson January 31stmarked the close of Stonepeak’s acquisition of Intrado Life & Safety. With...

Read More
Are You Ready to Step into the Public Safety Cloud?

Are You Ready to Step into the Public Safety Cloud?

Not All Clouds Are Created Equal We can all attest to a general shift toward cloud computing amongst the services and applications that touch our...

Read More
The Future of Public Safety through Artificial Intelligence

The Future of Public Safety through Artificial Intelligence

The term, “Public Safety", is often described as a wide array of government responsibilities that serve to protect citizens and communities from...

Read More
The Evolution of 911 and PSAP Data

The Evolution of 911 and PSAP Data

The information that Public Safety Answering Points (PSAPs) can receive today has come a long way since 911 service first debuted in 1968 (check out...

Read More