The Importance of LTE Interoperability
Tuesday, February 20, 2018 | Comments
In a data-centric world, interoperability takes on a whole new meaning. In public-safety references, it is the ability to share information from any source with any first responder across any network. This is the goal, and while attainable, it will take a lot of work.

The words “any desired data” could mean a number of data types. It could be citizen health information from an internet of life-saving things (IoLST) device, such as a heart monitor. It could be video from a surveillance camera at an intersection or from a citizen’s smartphone, or aerial images or radiation heat traces from a drone. The data could include a firefighter’s body temperature measured by an IoLST device sent from a person providing mutual aid to a large fire. It could even be information about a disaster situation that crosses country borders.

The second portion of the interoperability definition is “across any network.” The origin of data comes from many sources. In the case of citizen information input, it most likely originates in a commercial service provider’s network, then is routed through the appropriate next-generation 9-1-1 (NG 9-1-1) networks before being delivered to CAD systems and then to the first responders. Military network data must come across trusted gateways that don’t currently exist. Images from local government sources, such as traffic data, will originate from local networks. All data interconnections need to be defined, established and tested.

The key to interoperability lies in three steps: determine the needs, develop the interface standards or build gateways, and test. This can’t all be done at one time within any one group. It will take a large amount of cooperation — much of it between competing firms or standards bodies — but in the end, it will be beneficial to all concerned, especially first responders.

Determine Interoperability Requirements
The first step is to determine the needs. One example is the Association of Public-Safety Communications Officials (APCO) International Project 43 initiative, which looked at broadband implications for the public-safety answering point (PSAP). Committees comprised of engineers and public-safety first responders completed the report. One subcommittee discussed getting video from the citizen to the first responder. A first responder said that video is not shared between a first responder and a citizen. The ensuing discussion explored whether video is not shared between these two groups because existing LMR networks do not support it or because it has no value. This question and many others need to be asked.

Another significant effort in this area is the National Public Safety Telecommunications Council’s (NPSTC) “700 MHz Statement of Requirements (SORs) for Public Safety,” but it is clear that more work is needed in this space.

Interoperability insights are gained through the use of exercises and experiments. The Canadian-United States Enhanced (CAUSE) resiliency experiments demonstrate how technologies can enable Canadian and U.S. interoperability communications during emergency events. The three CAUSE exercises that Texas A&M’s Internet2 Technology Evaluation (ITEC) supported included a volcano eruption in Washington state with lahar flow into British Columbia; a brush fire that spread from Saskatchewan, Canada, to Montana; and a tornado touch down in Port Huron, Michigan, that jumped across the river to Sarnia, Ontario, Canada. Each situation involved a technical interoperability goal and allowed first responders to validate success.

CAUSE I and II were LMR-centric, while CAUSE III was the first to include Long Term Evolution (LTE) technology with basic data-sharing across two LTE cores, one in Canada and the other in the United States. CAUSE IV went further, testing voice and video session persistence across the two networks. CAUSE V, held last November, tested congestion management. Each experiment provided several other lessons learned, such as the drone video-sharing issues discovered in CAUSE V. This information is gathered at after-action report meetings, known as the “hot wash,” with first responders.

ITEC hosts another series of experiments through the Winter Institute. This year’s experiment will have a different format, focusing more on applications than the network. The goal of the Winter Institute is to generate first responder awareness of the power of the First Responder Network Authority (FirstNet) and to allow application developers to better understand the needs of first responders. The planning begins with a “call for innovation,” a blanket industry request for public-safety-specific applications.

Once responses are evaluated and applications approved, the experiment scenario is constructed. The application requirements are revealed, and the application is then integrated into the Winter Institute network during the next several months. First responders are recruited and trained on the applications the week of the experiment. During the past four years, ITEC has recruited first responders from Texas Task Force 1, a Federal Emergency Management Agency (FEMA) emergency response team; Texas Department of Public Safety (TxDPS); local law enforcement; and several other organizations. Once fieldwork is complete, the first responders are a part of a hot wash, where they share application strengths and weaknesses of the applications with developers. Because this information is more application specific, not as much data is disseminated to the public.

The 2018 Winter Institute will be held Oct. 22 – 26 in College Station, Texas, and will share general findings. FirstNet will be an active participant in this year’s experiment.

Develop Interface Standards
The second step toward interoperability is to standardize interfaces where possible and to build gateways where it is not. Standardizing interfaces is not new. As an example, the National Emergency Number Association (NENA) documents NG 9-1-1 interfaces in the NENA i3 specification. The documents do not dictate what a vendor has to do within an application or server; they simply define what the data needs to look like when it is conveyed to an upstream or downstream application or server. The Simple Mail Transfer Protocol (SMTP), which defines email transfer requirements, is an example of how a service can become global when standardized.

The standardization process is the best way to ensure interoperability, but the process is expensive in terms of man-hour expenditures and takes a significant amount of time to complete. Because everything cannot be standardized, gateways are used to fill the gaps. Data gateways allow information from one system to be reformatted to that of a competitor’s system, or a gateway can connect one type of network to another type of network. An example is the legacy network gateway (LNG) that connects an E9-1-1 system to an NG 9-1-1 system. The challenge with gateways is that they require continuous support to ensure proper operation because the networks or systems that they interconnect evolve.

Test, Test, Test
Whether interoperability is accomplished through interface standardization or gateways, the third requirement to ensure interoperability is testing. Testing is required even when interface standardization is available because all standards leave some room for interpretation. Clarification of these gray areas is where testing comes in.

Interoperable testing is done by all of the large service providers in their labs, but testing is typically limited to systems that lie within their own domain. These labs are expensive to run, and the results of their tests are usually shared with others outside of their own companies. Other interoperability testing includes plugfests where industry stakeholders get together for a week at a host site, connect to each other and test the interoperability. One example of this is the NENA Industry Collaboration Event (ICE). Each event has a focus, with the results being fed back into NENA standards committees for further refinement of standards. While these events have resolved several interoperability issues, the drawback of the ICE format is that the individual test results are not made available to the public. This was done by design because organizers could not gain industry support if they made the faults public.

A more recent example of a testing event is the mission-critical push-to-talk (MCPTT) Plugtests event that will be held at Texas A&M Universities’ Disaster City in June. This activity is the second such event sponsored by the European Telecommunications Standards Institute (ETSI), a standards organization. The first MCPTT Plugtest was held last year in France.

While this process may seem like a lot of work, the level of interoperability necessary for mission-critical communications cannot be attained without it. This will certainly not happen in just one location by one organization; it will need to be a community effort. Some work will occur in the AT&T and FirstNet facilities; some at the Public Safety Communications Research (PSCR) labs; and some in other federal, state and university labs. Certainly, there is no shortage of interoperability work to perform on the horizon.

Editor’s Note: The full version of this article is in the February print issue of MissionCritial Communications.

Would you like to comment on this story? Find our comments system below.


Walt Magnussen Jr., Ph.D., runs the Internet2 Technology Evaluation Center (ITEC), an emergency communications lab at Texas A&M University. He also has an appointment with U.S. Unified Community Anchor Network (UCAN), which oversees the Internet2 Broadband Technologies Opportunities Program (BTOP) grant for $96 million to build national infrastructure with a commitment to support public safety. He also served on the FCC’s Emergency Response Interoperability Center (ERIC) technical advisory committee and the FCC Communications Security, Reliability and Interoperability Council (CSRIC) work group seven. He is a member of the MissionCritical Communications editorial advisory board. Contact him at w-magnussen@tamu.edu.



 
 
Post a comment
Name: *
Email: *
Title: *
Comment: *
 

Comments
On 2/28/18, Bidisha Tunga said:
Very informative and useful read

Site Navigation

Close