For the system to be available at any time requires redundancy of all mission critical components.  There are three main components to an IP dispatching system.

The first is the dispatcher position.  Redundancy is typically achieved here by installing multiple positions.  While some stop-gap measures can be taken, such as purchasing high reliability components or even having multiple network drops, true redundancy requires multiple sets of dispatcher position equipment.  Two network connections will not improve system redundancy if the console position they are connected to fails.

The second component of an IP dispatch system is a protocol convertor and endpoint arbitrator .  The protocol convertor acts as a universal translator that allows “Any Endpoint” to be converted to a standard protocol that is passed to the dispatcher location(s).  The protocol convertor lies at the heart of the system, and to be available at any time it should be architected to run as a redundant pair of COTS servers, so that if one stops working the other can take over automatically.  These servers may be collocated, or may reside in separate facilities to also provide support for disaster recovery scenarios.  Because everything communicates across IP, these physical locations can change over time as needs grow or change.  In Scout, we call this universal translator VPGate, which stands for VoIP Protocol Gateway.  Our VPGate has more advanced interfaces than any other IP console.  In many cases we have been selected by the vendor as the launch console, and launch at or near the same time as the endpoint devices, which shortens time to market.

The other critical function of VPGate  is that it arbitrates which IP console has control of each endpoint device at any one time, and provides real time status indications to all other console positions so that each dispatcher can see the status of endpoints at their consoles at all times. 

The last component is the radio to IP gateway that converts legacy analog radio voice communications to IP and transmits those IP packets to the universal translator.  These radio gateways should be capable of functioning redundantly as well, so that if one stops working the other takes over automatically.  Since these gateways are connected to other radio equipment and that equipment might fail, even though the gateway is functioning fine, it is important to have a manual failover capability as well so the dispatcher can try the other gateway due to a radio failure.  In Scout, we call this radio gateway Outpost.  Outposts are fully redundant both automatically and manually as described above.

These blog posts have provided an overview of the eventual goal of interoperability that can be possible with an IP based dispatching solution.  We have highlighted best practices, and provided some insight in to why we designed our Scout console with the features it has today.

Connecting to any endpoint provides a new level of interconnectivity.  Allowing multiple dispatchers to communicate together with that endpoint, and for supervisors to override their staff, even when geographically dispersed, provides a higher level of collaboration.  Enabling this level of interconnectivity and collaboration to happen at any time provides the reliability necessary for IP based dispatching solutions to displace their hardware predecessors even in the largest, enterprise class installations.

We invite you to visit our website to learn more about Avtec’s Scout console .

The nature of dispatching requires communicating not just with resources in the field, but also with other dispatchers.  Groups of dispatchers often need to collaborate on an ad-hoc basis to solve difficult problems, or because of the specialty or level of authority required for a task. This capability is critical to a full featured dispatching solution, but is not present in many of the entry level IP based systems today because of the complexity of the implementation.  The best of breed systems, use software based applications to create real-time audio streams and pass unique audio mixes to each dispatcher, so they can each hear all of the other parties involved, but not an echo of their own voice.

This capability is different than a patch. From the perspective of a dispatcher, a patch is one dispatcher connected to many endpoints.  A patch can be efficiently created at the dispatcher location, because they are already connected to each endpoint and now want to mix that audio together in to a single stream.

Rather than a one-to-many relationship of a patch, collaboration between two or more dispatchers with an endpoint requires a many-to-one relationship.  The audio mixing for this collaboration would most efficiently happen from a central point within the system, not from a dispatcher location, otherwise one dispatcher location would receive significantly more audio traffic than the other locations and that could cause other issues in the system.

The diagram below shows how audio would need to be mixed in order for three dispatchers and one field worker to communicate.  The colors of the arrows show the direction of audio flow for each of the participants. Each participant receives a unique mix of audio from the other three participants.  No participant has the same incoming or outgoing audio mix as the other participants.

In hardware based solutions this mixing was done with centralized electronics.  Dispatchers have come to expect this capability as a standard feature and a core part of how the business functions.

An enterprise class, IP based system should allow any dispatcher to be brought into any conversation.  Dispatchers should have the ability to join or leave the conversation as needed.  Supervisors who have joined the conversation should have the ability to monitor or even override their staff.  All of these features should be unaffected by the geographic location of the dispatchers involved.

Today, there are practical limits to what can be accomplished because of factors such as bandwidth and network latency issues.  While working within the laws of physics and the customer’s network capabilities, an IP based solution still offers greater potential for dispatcher collaboration than has been previously possible because it is now economically feasible for dispatchers to be located across a wider geographic range and connected via IP to a common set of endpoints.

In our next post, we will discuss the phrase “Any Time” and talk about how to achieve high reliability with the interconnectivity and collaboration features that were discussed in the last two posts.

Avtec’s Scout is an enterprise class IP dispatching solution with support for dispatcher collaboration features such as the patches and conferences as described above, as well as supervisory takeover.  Scout also has user logins.  This provides security as well as “free seating”, where a user can log in from any location and have access to the tools and endpoints they need to perform their job function.  Dispatcher collaboration happens automatically as new dispatchers join the conversation by selecting the same endpoint.  Patches are created by any dispatcher with minimal screen touches for efficient operation.  

Sometimes the endpoints and console positions are distributed across a wide area network.  Under these circumstances, the amount of bandwidth to support the business needs can become difficult to model and expensive to deploy.  To address this issue, Avtec’s Frontier technology reduces network configuration complexity and bandwidth needs by automatically providing a unicast path across the WAN, and by gating audio transmission to only those consoles with active endpoints.  Frontier substantially simplifies networking requirements for distributed applications that require collaboration capability.    

These features and more give Scout the features and architecture necessary to meet the needs of even the largest of dispatching operations.

Any-to-Any

We tend to talk about interoperability with a phrase we first heard from one of our enterprise level customers: “Any-to-Any”. In other words, this customer wanted to connect any endpoint device to any dispatcher at any time. Over time we have realized that this is a theme among the majority of our customers, and we have taken steps to position our Scout console as the IP dispatch solution of choice for these environments.

In each post we will explain the concept and what best practices in IP dispatching should include. We will focus mainly on the technology and try to be objective in my explanations. We will conclude each post with a brief overview of how Avtec’s Scout console adheres to these best practices.

Any Endpoint Device

To break down this phrase, we first examine what is meant by Any Endpoint Device. An endpoint device can be a radio, and that radio could be on any frequency. It may be a land mobile radio, or an air-to-ground radio. It may be an analog radio, or a digital radio. It may be a P25 radio that is part of either a trunked or conventional system. It may be a radio based on a newer DMR technology, like MOTOTRBO from Motorola, or NXDN technologies like ICOM IDAS or Kenwood NeXedge. That endpoint may also be a telephone. It may be a POTS telephone line from a central office or a SIP telephone extension from an IP PBX. All of these endpoint devices represent a channel of communication needed by an organization to conduct their day-to-day business and must be available to the dispatcher in a seamless interface where patches and conferences can be created and torn down as needed.

But in an IP world, an Endpoint Device can be more than just a voice channel. An Endpoint can be any IP connected device. Web objects that give the dispatcher access to work instructions or weather reports or maps can be considered a type of endpoint. IP cameras can be considered endpoints. These cameras may be positioned at a courthouse, a treasury building, a park or street, or even a high school. These cameras could be part of a closed network, or publically available on the Internet. To provide the highest level of access, these IP connected devices should support open standards. Auxiliary I/O can also be considered an endpoint. Combining endpoints, a dispatcher can check a camera before unlocking a door.

“Any Endpoint Device” is really a shorthand way of saying “any piece of information, whether it is voice, data, video, or a combination of these, which may be of benefit to the dispatcher to help them work more efficiently and with greater accuracy.” While there are practical and financial limits to what can be achieved, organizations can now analyze these tradeoffs and construct a system that best meets their needs. An IP based dispatching system, especially one based on open standards, moves us closer to “Any Endpoint Device” interconnectivity than has been previously possible.

In our next two posts, we will explore the phrases “Any Dispatcher” and “Any Time”.
Avtec’s Scout console has more advanced interfaces than any other console, thus bringing us closer to meeting the “any endpoint device” standard than any other solution. In addition to radio and telephone endpoints, the dispatcher interface is completely customizable, including the ability to add web objects, endpoint devices, and auxiliary I/O controls as described in this post.

12/6/2011 – PowerSouth Energy Cooperative, a leading utility provider, will share its experience with IP dispatching & recording during a live webcast at 1 p.m. EST.  Join subject matter experts from PowerSouth Energy Cooperative, Avtec, and VPI to learn:
- How PowerSouth modernized its contact center and boosted reliability and quality control with a state-of-the-art IP dispatch and communications recording solution.
- The compelling advantages of an IP infrastructure for emergency communications.
- Best practices for disaster recovery.
- Proven strategies for recording and quality assurance of your communications.
To register: http://t.co/nWpDezxz.

To watch the Webinar click the .wmv icon below: