The path to a better PSAP

Over the next few years, IP networks will play an increasingly important role in emergency management within next-generation 911 call centers. Effective management of day-to-day operations and emergency events will involve many forms of communication and require coordination and collaboration across both jurisdictions (city, county, state, federal) and technologies (telephony, radio, cellular, wired, wireless, satellite, video, data).

IP networks already are coming into play. In states such as Colorado, Indiana and Montana, such networks have been adopted by numerous public-safety answering points (PSAPs). The federal government also is signaling that it will back the transition to IP communications. In April, the U.S. Senate held hearings for the IP-Enabled Voice Communications and Safety Act of 2007 (S428), legislation that would further enable IP-based E911 deployments throughout the nation.

Why is IP regarded as an important part of the future of the public-safety network? First and foremost, a converged IP network has no single point of failure. Second, unlike traditional telephony technologies used in 911 centers, IP has the ability to support mobile voice, video and data applications. Users can communicate and collaborate easily over an IP network backbone, largely because the intelligence and routing protocols are distributed in the network — which makes the overall system highly flexible, available and reliable. This capability is invaluable for a network that must support essential government services and provide continuity of operations during emergencies.

Moreover, IP-based communications systems are highly scalable, enabling them to better handle unpredictable traffic surges caused by major incidents and emergencies. In contrast, many legacy, TDM-based PSAPs failed during the 2005 hurricanes, hobbling communications for emergency workers in several Gulf Coast states. Incredibly, more than 50 of these PSAPs still remain inoperable.

IP systems also provide significantly enhanced communications interoperability. Agencies easily can preserve their investments in traditional communications and radio technologies while extending the functionality of their systems to desktops, IP networks and satellite networks. This enables communications with first responders beyond the reach of traditional radio systems, via PC, IP phone, telephone, text message, page or e-mail — wherever an IP network packet can reach.

In addition, new communications devices can be integrated at a fraction of the cost of complete system replacements or the cost of integrating them into traditional non-IP environments. Thus, IP convergence enables direct collaboration for anyone on the network, reaching far beyond communications that in the past have been limited to a dispatcher and a radio user.

Given the many strengths of IP, many PSAPs logically are discussing moving their communications network to an IP-based infrastructure. However, some aren’t sure where to start. The questions they’re now asking are: How do I make that migration; what might my IP migration plan look like; and how do I get there?

Naturally, the architecture of any IP network will differ from agency to agency, depending on each PSAP’s unique requirements. However, the following guidelines should help readers begin to think about how their networks will take shape and what they might ultimately look like.

Step 1: Analyze your goals

First, you must define clear goals based on the needs of your PSAP and its end users. During this analysis, you’ll want to get answers to a number of key questions. These include:

• What do I want my infrastructure to accomplish?

• How extensive should it be in terms of users?

• What types of applications do I want it to support?

• Do I expect to link with other jurisdictions or emergency centers?

In designing a network, it’s best to define your goals and work backward from there. The answers to the questions above will help you accurately match the outline for your network design with its desired functionality. As your project proceeds, you should continue to weigh your requirements and ensure your architecture is helping you meet them.

At this stage, you must keep in mind the needs of your users. It’s shocking how many projects begin with little or no input from an organization’s end users. Right from the beginning, you must take into consideration what your users require, how they work and how they will use the technology. In the case of public-safety agencies, users include everyone from 911 call takers to supervisory staff to emergency workers in the field. Their needs and goals must be communicated clearly to the project team and taken into account during the entire process of planning and building out the network.

Step 2: Assess your current infrastructure

Many PSAPs already have installed a small IP-based network, probably to share data. If an IP network is in place, you’ll have to assess whether it’s capable of supporting converged voice, video and data applications. In all likelihood, existing IP networks will have to be upgraded, both in terms of hardware (routers, switches, gateways and servers) and in terms of services (quality of service, security and multicast capabilities).

Compared with TDM networks, IP networks are relatively easy and cost-effective to upgrade. Therefore, many PSAPs will have the option of adding devices and capabilities to existing IP networks. Others may choose to start from scratch with a new design and architecture. An IP network is an investment that increases in value over time — it does not have to be “ripped and replaced” the same way legacy PBX and radio systems do. IP extends the lifetime of existing voice, video and data systems.

At this point, you also should assess your users’ skills. For instance, you will need to determine how much training employees will require to effectively use the system. Chances are good that they will need to be trained because converged operations will open up new possibilities and far greater flexibility in terms of how people work, where they work, what capabilities they have and how they access resources. Also, policies, procedures and work practices will change considerably. Training will take some time, so it’s best to start early.

Step 3: Create a network architecture

You will need to map your network architecture in as much detail as possible. Account for all facets of your environment, including the number of facilities, number of employees and types of applications. As you sketch out the architecture, remember to build maximum flexibility into your design. In the future, there may be new facilities, additional employees and more applications coming online.

Obviously, network architectures will vary depending on the needs and goals of each agency. Still, networks generally will share a common set of elements that support the robust capabilities that most PSAPs require.

An IP infrastructure, which may connect many PSAPs over wide-area network transport services, provides the ability to locate resources anywhere on the network and distribute applications, roles and responsibilities where needed. The building blocks for an IP network include network gateways that provide for redundant communication paths, network-enabled communication servers, and integrated client and workstation applications for managing large call volumes in high-pressure PSAP environments. An IP-enabled PSAP network infrastructure also features redundancy and resiliency so that the network is always operational.

Step 4: Deployment

If well-planned and architected, the network’s deployment should proceed fairly smoothly. The deployment should follow a detailed schedule that realistically reflects your team’s resources and your organization’s needs. Deployments do have a tendency to fall behind schedule, so it’s important to do everything possible to keep them on track.

Many PSAPs are very small (fewer than three seats), so they typically will employ a trusted implementation partner to design, deploy and, afterward, manage and support their new IP-based infrastructure. Also, the partner probably will train users on the system. Therefore, most PSAPs won’t need to have a high level of technical skill in-house. That said, it’s up to you to make sure that your integration partner understands the expectations of your users and how the deployment will meet their needs.

One final point must be mentioned: The technical aspects of building an IP network are well-known, and outside expertise is readily available. Therefore, for many PSAP agencies, the main challenges will be non-technical and include such factors as budgets, priorities and policies. Many PSAPs enter projects somewhat daunted by the perceived technical challenges. Those concerns, however, usually are easily addressed. The other, non-technical challenges often present the greatest hurdles in a deployment.

When an IP network is deployed, its potential benefits are enormous. A properly designed IP backbone is inherently scalable, so it can support many new users, applications and response capabilities. And with no single point of failure, it is highly reliable, resilient and able to handle use surges during emergencies.

PSAPs also are impressed by the ability of an IP-based infrastructure to support new types of multimedia applications. For instance, some PSAPs are considering applications that will allow both callers and personnel to upload pictures instantly and video directly from an emergency site. Because an IP infrastructure can support video, voice and data, these applications likely will become widespread in the near future.

In the end, IP-based communications will deliver the world-class collaboration, scalability and reliability that PSAPs require during this time of rising emergency incidents, rising incident severity, and rising expectations of both users and citizens. These guidelines should help them along the path towards executing this critical migration.

Morgan Wright, a former state trooper and police detective, is Cisco Systems’ global industry solutions manager for public safety and homeland security.