User:Telecom881/sandbox for 881

Overview edit

Through the reporting of emergency events such as the World Trade Center attacks, the Columbine School shootings, the Katrina hurricane, and most recently the Deepwater Horizon oil spill, the problem associated with the lack of coordinated communications between first responders and other organizations has become evident. The problem is easy to describe but not simple to solve. Many solutions predating the listed events have been proposed over the years and yet the problem still exists at all levels of the government and throughout the private sector as well. Relying on new technology is necessary but not sufficent to address this problem. This article provides some insight into the problem, its scope, and a description of how one company has developed a solution that addresses the obvious as well as subtle issues that have impeded the progress in solving this problem once and for all.

Public Safety Interoperability Issue edit

The issue of a lack of interoperable communications in the public safety sector came to the forefront after the events of September 11, 2001. The 9-11 Commission discovered that a lack of interoperable communications between fire and police was a serious problem that hampered evacuations and contributed to the deaths of personnel during the attacks on the World Trade Center buildings.[1]


Interoperability Definition edit

The Department of Homeland Security (DHS) www.dhs.gov National Emergency Communications Plan (NECP) [2] defines interoperability as follows:


Interoperability-- "The ability of emergency responders to communicate among jurisdictions, disciplines, and levels of government, using a variety of frequency bands, as needed and as authorized..."


The implicit communications capability within this definition is centered on the Land Mobile Radio Service, commonly referred to as LMR or two-way radio. It does not specifically address other forms of communications such as real time video, data exchanges, or file/image transfer. The definition also focuses solely on governmental agencies.

Expanded Emphasis edit

Later DHS based policies recognized and embraced a broader notion of interoperability through a broad based and scalable inter-agency and inter-jurisdictional collaboration approach to emergency preparedness, response, and recovery. Specifically, the National Response Framework (NRF)[3] details how all levels of the government, private companies, and non-government organizations (NGOs) need to be involved in the response to natural and man-made disasters, referred to as an “all hazards, all disciplines” approach as described in the National Response Plan (NRP). This notion of broad based interdependency and collaborative emergency response is also implemented in the DHS’ National Infrastructure and Protection Plan (NIPP)[4] and the National Incident Management System (NIMS)[5].

Solution Approaches edit

Over the years many different approaches have been implemented to address this problem. Virtually all of them are in use today. To some degree these system address certain aspects of the interoperability problem. The table shown below summarizes, in general terms, the most common approaches implemented in the past.

Approach Communications
Focus
Comment
Swap radios between agencies On-site two way radio communications Helps on-site public safety personnel only, requires a stock pile of radios to hand out
On-site radio cross-patching On-site two way radio communications Helps on-site public safety personnel only, allows each group to use their own radios
Dispatch Console cross-patching Two way radio system interconnection Only works when one console (agency) can take control of multiple agency radio systems
Common radio channel Two way radio communications Requires all agencies to operate in the same frequency band and share a common radio channel
Common, shared radio system Two way radio communications Requires eligible agencies to purchase and participate in the same system

As is obvious from the table, all of the past solutions have focused on two way radio voice communications. Also, in virtually all instances, the solutions have only focused on providing the ability for police, fire, and in some cases EMS personnel to intercommunicate. The comnunications needs and inclusion of other public agencies and private enterprises were largely ignored by these solutions.

In the past seversal years a number of systems have been introduced that makes the interconnection of these voice systems easier. Although addressing the "under the covers" technical issues, the scope and limitations of the systems remained. The technique involves converting the audio and, in some cases, the required radio control signals to a common digital format, interconnecting the resulting data streams, and then converting the common audio data streams back to the native format for each connected system.

One company has taken this common digital format technique to an entirely new level that expands the concept of interoperability in a number of directions as described below.

Mutualink, Inc. edit

The company that has expanded the entire interoperability concept is Mutualink, Inc., (www.mutualink.net). It is a privately-held U.S. high technology corporation founded in 2005 and headquartered in Wallingford, Connecticut. It also has development facilities in Westford, Massachusetts, and Mayaguez, Puerto Rico. Mutualink develops and manufacturers an advanced interoperable communications and real time collaboration system designed for public safety and military environments. The system is unique in that it broadens the scope and solution set as outlined by the Federal Government by providing a state-of-the-art method of providing a community-wide approach to providing a communications collaboration environment useful in response to natural and manmade disasters.

Compatible and Compliant with National Goals edit

Mutualink’s multimedia interoperability system is designed to meet the goals of the NRF, NIPP and NIMS by offering a resource sharing platform that accommodates various forms of telecommunications including radio, telephone, video, and data which can be used by both public and private entities. The system provides a multimedia, peer-to-peer information sharing appliance architecture that allows users of all skill levels to collaborate in crafting their planning, response to, and recovery from emergency incidents.

The technical communications diversity allows new communications systems as well as existing and vintage systems to intercommunicate. No longer are system upgrades or large scale system replacements required to allow inter-agency and inter-enterprise communications.

There have been many technical solutions proposed and implemented in the past and there are a variety of technical solutions available today. However, the technical aspects of addressing the interoperability issue are only one part of the overall solution. A number of other considerations are equally important some of which are described below.

Interoperable Communications – Maintaining Sovereign Control edit

Mutualink’s interoperable communications system is designed to enable scalable multimedia interoperable communications for public safety and first responder agencies and other entities that provide critical infrastructure and manage key assets. Mutualink extends traditional notions of interoperability beyond radio communications to include other voice, video and data sharing capabilities to provide full real time collaboration capabilities among virtually any agency or enterprise. In addition to voice, video and data collaboration, Mutualink is distinct from other interoperability products in that it is a distributed system with no centralized servers. This enables each agency or entity to retain both physical and logical control and jurisdictional sovereignty over its communications and information assets. Historically, agencies were hesitant to relinquish control of their communications resources to some designated authority. This hesitance was quite natural due to differing priorities and responsibilities among agencies as well as government restrictions.

Leveraging Available Resources edit

In the past, the burden of responding to emergency incidents has centered on public safety agencies. In many cases, all other personnel and entities were viewed upon as either victims or burdens that had to be dealt with during the actual incident response. In actuality, the non-public safety entities can and have provided valuable capabilities that have saved lives and property countless times. An excellent example of community-wide involvement was the response from multiple entities during the "Miracle on the Hudson" response to the downing of US Airways Flight 1549. During this remarkable response, a ferry boat arrived on scene and began rescuing passengers within four minutes of the plane's landing in the Hudson River. The private sector and non-public safety agencies are, for the most part, ready, willing, and able to respond. The key ingredient to the effectiveness of their responses is real time, communications capabilities among all invovled parties. Providing this capaiblity was a key driver in the design of the Mutualink system. However, not all entities are required to participate in all incidents. The ability to selectively involve (i.e. "invite") entities to participate and in turn, allowing the invitees to selectively decide to become involved (i.e. "accept) the request is vital to providing order during the response and recovery efforts.

Robustness is Critical edit

Mainframe or centralized systems and distributed Client-Server architecture models have proven their effectiveness and are deployed in virtually all remote computing applications where the user is not in direct, physical control of the computing environment. Centeralized systems are also used in many communications systems such as cellular networks and advanced public saftey radio systems. The key to their success is the availability of the network and the centralized hardware and software components themselves. Additionally, these systems are designed to accommodate certain predicted levels of service requests to maintain a certain quality of service [1] to the users. During major, wide spread incidents such as hurricanes, tornados, or targeted manmade facility attacks, these centralized resources may be compromised. Also, during incidents, communications system may simply become overwhelmed with traffic and become unavailable or experience exceedingly long wait times for service making collaboration difficult at best and impossible at worst. This situation can be avoided with peer-to-peer architectures that do not rely on centralized servers or controllers. In peer-to-peer systems, each communication endpoint device is knowledgable of all other endpoints and knows how to directly reach them and establish a communications path between them without the aid of an intermediary host server. This capability signficantly increases the overall robustness of the system by eliminating single points of failure and avoiding common point network congestion.

Incremental Implementation edit

With such a diverse set or participants potentially involving all levels of government and many enterprises in the private sector that should become involved in developing a community-wide communications collaboration system, it is exceedingly difficult if not impossible to expect all public and private entities to be able to commimt to the implementation of a system at the same time. Federal and State grant cycles alone can be measured in years. Therefore, the architecture and required implementation of the system must take this fact into account. Further, as implementation is underway some participants may also be making incremental additions or even wholesale change outs of their communications systems or their capabilities. Finally, existing users of the collaboration system must not be unduly burdened with retraining thier personnel or making complex configuration changes to accommodate new users or resources as they are added to the system.

To accommodate the incremental implementation environment, the Mutualink system has been designed to allow new users (agencies or enterprises) to be added to the system at any time with their presence automatically added to existing collaoration system through no efforts on the part of existing users. New users simply appear as available resources that are now available. Similarly, if a resource becomes unavailable either permanently or due to connectivity or equipment failures, that resouce is automatically removed from the available resource pool.

Mutualink Interoperable Communications System Overview edit

The Mutualink System consists of three major components that can be visualized as three concentric rings. Each ring can incrementally grow to accommodate a virtually unlimited number of users or communications subsystems over any size of area.

Data Backbone Network edit

The innermost ring at the center of the model is referred to as the Mutualink Preparedness Network. It consists of a fully redundant, private, high bandwidth, secure IP based backbone that interconnects all other components in the system. Through Mutualink supplied wire line or wireless VPN Routers, IPSEC GRE,[6] secure tunnels are established that link all of the endpoint devices (described below) across LANs, WANs and or the Internet. Only preconfigured, authorized, and authenticated devices can participate in the network. The network operates in a peer-to-peer mode without the need for central coordination by servers with each endpoint device having equal privileges. Endpoints at public safety of private security facilities can be connected to the network with dedicated wire line or wireless links or through virtual, firewall protected LANS. Processes within the network provide automatic self-discovery of newly authorized endpoints, automatic software upgrade downloads to all devices, and network and device heartbeat/availability monitoring and the collection of operational and device statistics. All messages over all links in the Preparedness Network are encrypted following the AES 256 Standard.

Network Interface Controllers edit

Network Interface Controllers (NICs) are connected to the Preparedness Network and form the second or middle concentric ring in the overall system. Each NIC acts as a highly intelligent interface and protocol converter that links the IP backbone Preparedness Network and the particular customer supplied communications device. A family of NICs has been developed to interface to virtually any type of multimedia communications systems.

NICs are available to connect to:

  • land mobile radio systems
  • the public switched telephone network
  • cellular systems
  • cellular systems with Push to talk capabilities
  • intercom and public address audio systems
  • analog and digital video systems
  • virtually any other IP based communications system

Intelligent Radio Interface Capabilities edit

The Radio Network Interface Controllers or R-NICs are designed to accommodate a wide variety of legacy and new radio systems. For example, they can connect to the Nextel™ system, EIA Standard Tone Remote[2] Control base stations[7] or control stations, and locally controlled radio equipment. The R-NICs can also be connected to and control trunked radio systems including the Association of Public Safety Communications Officers (APCO)[3] Project 25 widely accepted set of radio system standards , with unique circuitry that monitors the channel allocation process and buffers audio until a channel becomes available. The R-NIC’s capabilities exceed the capabilities typically associated with other Radio over IP (RoIP) approaches. Many of these devices simply convert the transmitted or received audio from a radio channel to IP packets and then transfer them to another point via an IP network. In addition to performing the RoIP functions, the Mutualink R-NICs contain circuitry and logic to accommodate virtually any control schema or audio configuration found in legacy or new state-of-the-art radio systems.

Interoperability Workstations edit

The Mutualink Interoperability Workstations (IWS), in various physical forms, are endpoints that connect to the data backbone Preparedness Network and, like the NICs, are part of the second or middle concentric ring in the conceptual model. The peer-to-peer IWSs are the controlling points that allow users to establish, control, and monitor incidents through the allocation of their own communications resources and by inviting other entities to join in the incident as they see fit. The patented [8] concept of inviting others to join an incident and allowing the invitees to accept or reject the invitation and then unilaterally make their communications resources available sets the Mutualink system apart from all other interoperability/collaboration systems. Each IWS operator, through a simple to use, drag and drop graphical user interface can choose to add radio, telephone, or video resources to the incident and share them with other participants. Locally stored or accessible files such as procedures, pictures, graphics, or floor plans can equally be shared with others. IWSs are available in three form factors: a desktop computer, a rugged laptop computer or a standard Smartphone running the Android™ operating system over the Verizon Cellular Network. With these multiple form factors, users can control the collaboration network in dispatch centers, in command vehicles, or even while in the field en route to or at an incident.

Communications Subsystems edit

The third portion the system consists of each participant’s existing communications system(s). These systems are connected to the appropriate Network Interface Controls (NICs) which, in turn, link all of the communications systems together through the IP backbone Preparedness Network. The communications system may be land mobile radio systems, operating in any frequency band with any protocol, Nextel, cellular or public switched telephone, cellular PTT services, voice intercom or public address, analog or digital video, or an IP connection to other devices such as PC connected Internet access devices. Subject to bandwidth considerations, there is no limit to the number of communications systems that can be equipped with NICs and no limit to the number of IWS devices that can be used to establish, control, and monitor incidents. Other solutions that use centralized servers are constrained by the processing limits of their servers.


Usage Examples edit

By using combinations of Network Interface Controllers (NICs) and Interoperability Workstations (IWSs), connected to the backbone IP Preparedness Network, any size collaboration network covering any size of geographical area can be accommodated. The following is a list of the types of locations and applications that have been deployed and are in operation today.

Land Mobile Radio Applications
Usage Dispatch Mutual Aid On-Site Maintenance Security
Law Enforcement Y Y Y    
Fire Y Y Y    
EMS Y Y      
EOC Centers Y Y      
Hospitals       Y Y
Schools       Y Y
Universities       Y Y
Shopping Malls       Y Y
Emergency Comm Vehicles Y Y Y    
River Response Vessels Y Y Y    
Financial Institutions       Y Y
 
Media Radio Wireline Voice Video
Usage Nextel™ Cellular PSTN Intercom/PA Surveillance
Law Enforcement     Y    
Fire     Y    
EMS Y Y      
EOC Centers   Y Y   Y
Hospitals Y Y Y Y  
Schools     Y Y Y
Universities   Y Y Y Y
Shopping Malls   Y   Y Y
Emergency Comm Vehicles Y        
River Response Vessels   Y      
Financial Institutions   Y Y   Y


As of September 2010, the New Jersey Preparedness Network [9] consisted of forty-seven different IWS equipped locations made up of 16 public safety agencies, 24 hospital and medical facilities, and 7 community sites (shopping malls, schools, and arenas). A total of 187 endpoints devices (NICs and IWSs) are in use in the system that are spread over six counties presenting 3.9 million residences. Through a variety of Federal and State grants and other budget allocations, the system is expected to more than double over the next several months.


Interoperability Impediments edit

There were five major reasons identified in the DHS SAFECOM [10] “Why We Can’t Talk” Study page 15 [11]. As the study’s name implies, the focus of the study was on voice radio communications. It also focused on public safety law enforcement, fire, and emergency medical services agencies only. However, its findings can be easily extended to multimedia communications (voice, data, and video) and to private sector and NGO entities that are or need to be involved in incident responses. Mutualink has addressed all five reasons as described below:

“Reason 1: Incompatible and aging communications equipment” edit

As pointed out in the study, some agency communications equipment is more than 20 years old. Although there are many new systems and products available including APCO Project 25 systems, many agencies, under extreme budget pressures cannot afford to upgrade their systems in today’s economic climate. Additionally, many entities have a hard time justifying new systems “just” to support communications interoperability. Although there is a growing shift to IP Video, most existing video monitoring systems use analog video signals and, again, converting all of them to a new protocol may be cost prohibitive. By using highly intelligent network gateway devices (NICs) and converting all communications protocols to IP, Mutualink can support virtually any type of legacy or current communications system. As agencies and entities update or expand their systems with new equipment, there are no or minimum changes to the Mutualink system thereby allowing entities to use what they have today and upgrade independently as they see fit.

“Reason 2: Limited and fragmented funding” edit

Through efforts in a number of funding sources in the Federal Government, agencies have been encouraged to seek regional grants to help address the interoperability issue. Unfortunately, not all agencies or organizations qualify for certain grants or the organizations’ priorities may be diverse enough to prevent coordinated funding. Private sector entities, not eligible for these programs also may have different priories and timing. The Mutualink system allows straightforward, incremental additions to the system as entities join the Preparedness Network. In fact, existing devices on the network automatically become aware of the new devices and there are no re-configuration activities required by the existing users. This capability allows existing users to expand their collaboratioin capabiliities and new users to join the Preparedness Network any time that funds become available. With no common equipment to purchase and low cost of each component, the entry barrier is very low, within the reach of virtually any agency or enterprise.

“Reason 3: Limited and fragmented planning” edit

Again, through the efforts of various agencies within DHS and many of the states, agencies have been encouraged to follow national guidelines and work on a regional basis. These leadership efforts have resulted in far more efficient, larger scale planning. The Mutualink system with its all-inclusive nature of allowing entities eligible in different FCC radio services [12] to interoperate when and if each entity so chooses has significantly simplified the planning process. With this arrangement, interoperable, multimedia, collaborative sessions can be established on an ad hoc basis with each entity controlling their own communications resources and making them available when and if required. In most instances, this arrangement negates the need for pre-determined Memorandum of Understanding [13] agreements between various combinations of agencies and enterprises. This is especially valuable when considering the overall goal of creating an overall community-wide all hazards response network.

"Reason 4: Lack of coordination and cooperation” edit

As described in the Reason 4 description of the Why We Can’t Talk study report [14] “The human factor is a substantial obstacle—agencies are naturally reluctant to give up management and control of their communications systems.” With the Mutualink system’s capabilities of limiting the control of each communications resource to the owning jurisdiction and allowing each owner to determine when and if their resources should be added to the incident collaboration session, the reluctance of participation and cooperation is greatly diminished. Thne system also allows dispatch personnel to hold private conversations independent of all field users to further coordinate their activities and can set up separate, private collaboration sessions on an ad hoc basis between any group of dispatch and field participants. These capabilities allow far more effective coordination of activities during critical periods.

"Reason 5: Limited and fragmented radio spectrum” edit

The issue of limited and fragmented radio spectrum is further complicated by including private enterprises and NGOs in the overall interoperability collaboration system due eligibility restrictions and requirements of the Federal Communications Rules and Regulations [15]. In essence, different entities are restricted from using common radio channels. Through the process of tying communications resources together with a common baseline, standard IP protocol, the Mutualink system resolves this issue. Each entity can continue to use their own licensed and unlicensed spectrum but can still intercommunicate with each other.

Summary edit

As described above, the solution to the so called "interoperability problem" in which "people cannot talk to each other" has many underlying requirements necessary to provide a complete solution. It must include the sharing of information, in any form, between participants to allow meaningful dialogue and collaboration to take place and allow individuals from multiple agencies to make informed, real time decisions. Below is a list of those requirements. Although the overall list may seem intimidating, upon careful examination of each item, all are required.

  1. Maintain jurisdictional integrity through sovereign control of communications resources
  2. Compliant with DHS requirements as stated in the National Response Framework, National Response Plan, and National Incident Management System guidelines and requirements
  3. Allow the formulation of ad hoc collaboration groups to accommodate unforeseen resource combinations
  4. Allow the rapid establishment of collaboration session with pre-defined user groups
  5. Support multiple exclusive collaboration sessions
  6. Simple and fast movement of participants from one session to another
  7. Useful in a day-to-day use to improve normal communications and help insure user familiarity during high stress emergency situations
  8. Simple graphic user interface with drag and drop capabilities requiring minimal training of personnel
  9. Support fixed location, in field, and mobile establishment, monitoring, and control of collaboration sessions
  10. Support for both real time voice and video communications systems in a variety of analog and digital formats and protocols
  11. Accommodate legacy communications systems of varying protocols and capabilities
  12. Be independent of radio channel frequencies or FCC usage restrictions
  13. Support communications systems including:
    1. Land Mobile Radio (conventional and trunked system)
    2. Nextel™
    3. Cellular
    4. Push to Talk Cellular
    5. POTS and ISDN Telephone Service
    6. Intercom and Public Address Systems
    7. Analog Video
    8. Digital Video
  14. Support file and image sharing between endpoint devices and agencies
  15. Accommodate incremental expansion of entities
  16. Accommodate incremental expansion of communications sub-systems as they are added or changed
  17. Encrypted, authenticated, and authorized communications secure connects for among all components
  18. Peer-to-peer architecture to provide increased robustness and avoid network bottlenecks
  19. Support for wireline and wireless connectivity in any combination among endpoint devices
  20. Automatic discovery and availability of resources as they join the network
  21. Support for automatic backup of network connections with automatic restoration of active collaboration sessions
  22. Background continuous monitoring of communications to all end point devices to identify network or device degradation or failures

References edit

08Dec2010