Imagine a row of terraced houses and that someone has bought two of them with a view to knocking through the connecting wall. From the outside all seems well, but the owner quickly discovers that all the electrical wiring in one uses AC, the other DC, while the plumbers responsible for the dwellings have used different gauges of pipe. Motorola Solutions’ Jeppe Jepsen uses this analogy to highlight the many problems that have to be overcome before public safety agencies across an international border can easily communicate with each other.
In Northern Europe, we have many open borders, significant migration issues, and a high threat level from terrorism. As public safety agencies work across these they face different languages, different processes, or even different communications systems. At the same time, criminals and terrorists operate across borders and are not restricted by rules. Given today’s challenges, public safety agencies need to respond to events and intelligence quickly and effectively. For example, connecting police cars as a suspect crosses a border, or calling up resources from a hospital or medical centre on the other side that is much closer to the emergency.
Developing a project – lessons from the EU ISITEP programme
With open borders in Europe between the countries in the Schengen Area, there is a clear need for rapid communications between agencies from different countries. The European ISITEP programme established working groups to design a process by which two or more countries could establish cross-border communications using TETRA or TETRAPOL. Representatives from many EU nations joined together in workshops to share experience and identify the interworking issues. In addition, two demonstrations were held to test the technical and operational solutions. The first simulated a joint police surveillance patrol in Spain and Portugal, held at the Leonardo facility in 2016. The second demo, also in 2016, simulated an air disaster at Geneva Airport. The ISITEP programme (www.isitep.eu) is now complete and the output is available to any agency beginning the cross-border interconnection process.
This work has highlighted the key steps for any new interconnection programme. The first is to recognise that any such programme is a major undertaking requiring a willingness at a high level to work closely, and allocate significant resources and finance. The Sweden and Norway programme has had support throughout from ministers, senior leaders allocated to drive the project, and regular meetings between local personnel, which in some cases have created cross-border friendships.
Any new project needs this foundation, but how to engage with political leaders and win their approval and commitment? Here there is a need for co-operation between senior leaders in public safety in each nation to jointly make the case for the project to their governments. Highlighting recent examples of emergencies, where there were severe consequences that could have been mitigated with better communications, would strengthen the case, while communicating the economic cost of such incidents will help to free up finance.
Any project plan needs to be realistic in terms of the technical issues to be overcome if the networks are provided by different suppliers, as well as the time and effort required to harmonise working practices and terminology in cross-border working. Taking a simple example, an inspector in one force may be a captain in another. Fire equipment may not be the same, and medical terms and procedures will differ. Language may be the single biggest obstacle, but border regions may have a hybrid dialect understood on both sides or a commonly spoken third language.
Existing projects in public safety or other areas can be used as clues for the likely costs and structures of the project during the planning stage. Personnel from these may later be co-opted into the project, bringing valuable experience and cross-border contacts. Where technical adaptation of the networks is required, manufacturers will need to be involved, and may require finance for bespoke developments.
The ISITEP guidelines describe how to document the end-user needs and requirements. The Norway team stressed how important this was and the need to involve end-users at every stage to ensure that the solutions would be fit for purpose.
Once a project has been given high-level approval, the working team can be assembled. Officers or contractors with strong project management skills will be a big help here, but a senior owner should be identified on both sides who will jointly chair a steering group overseeing progress and costs. The Sweden-Norway project had regular working meetings at a hotel/conference centre close to the border; such an arrangement may be convenient. These working teams are probably best staffed by officers and end-users who will be working closely together during real-life emergencies.
A highly successful strategy used by both the ISITEP and Sweden-Norway projects has been to simulate situations to test technology and operational processes. In the case of ISITEP, a simulated air crash near Geneva Airport was set up, with communications equipment made available to make live calls. Workshops with user organisations were held at the CERN research establishment, which acted as a host. These exercises provide a degree of reality and highlight where joint processes need further refinement. Where technical developments are running in parallel, these can be trialled in a non-safety-critical environment so that issues can be logged for resolution afterwards. There can also be a degree of ‘stress testing’ of the systems to determine whether they are resilient to the levels of traffic likely to be seen during an emergency.
The solution will need clarity regarding command and control processes and responsibilities. How will control be assigned, both back at the main control centres and in the field? This may be one of the most difficult areas to determine and will require a high level of flexibility and goodwill. Alongside this is the need to consider security and access – will users on one side of the border be able to access subscriber listings and numbers or other sensitive information? This is not a trivial issue and one that needs to be carefully considered when designing the system.
Sweden, Norway and now Finland
In parallel with the ISITEP programme, Norway and Sweden moved to establish common TETRA talk groups and processes to be used by their public safety agencies in the event of an emergency on their long border. This programme has been reported on in previous issues of TETRA Today, but the main lessons can be underlined here. Motorola Solutions and Airbus worked to ensure that their networks could be connected. A set of single and multi-agency talk groups were established with easy-to-understand designations. These could be single-agency, such as fire or police, or multi-agency. In all cases, users from both countries have access.
A large part of the Nordic programme was to establish common working processes and a clear understanding of roles and command. Sweden and Norway speak different languages, though in the border region the differences are less pronounced. But it still took a great deal of time, energy and goodwill to agree how these cross-border incidents would be handled. The programme led to a major demonstration and exercise held on the border near Trondheim in November 2016, at which police, fire and ambulance teams from the two nations attended a simulated coach crash involving many casualties. A video is available to illustrate the event. The formal agreement between them was signed at ministerial level that day. A short time later, Finland agreed to join the programme.
The Sweden-Norway project took about two years to complete, this between two countries with similar but not identical languages and a history of co-operation in many areas. More recently, Norway and Finland signed an agreement to develop Inter System Interoperability between their forces in Lapland. As reported in TETRA Today in December 2017, calls between the Norwegian and Finnish networks have been demonstrated and work on rules for co-operation will continue. Finland and Sweden are also now working on an Inter System Interoperability solution and the third joint workshop will take place in March 2018. Once all of these projects are complete, emergency forces on the two sides of all three borders will be able to communicate when needs arise. The area where the three countries meet is remote, so will there be a need for three-way Inter System Interoperability, or will this be dealt with through agreed procedures?
Airbus says there will be three-way Inter System Interoperability in place between Finland, Sweden and Norway. One talk group from any of the three countries will be linked to a talk group from the other two countries. One country will be in control of that shared three-country group (with the other two countries present as participating groups). This procedure was technically demonstrated during an ISITEP test in Brussels where two Airbus networks and one Motorola network were connected.
As for three-country full functionality, a few features have been put in place already, but these need to be tested to verify the solution. For example, a Finnish terminal roaming from Sweden to Norway (between two visiting countries) or a Finnish terminal making a call from Sweden to Norway (e.g. call over Inter-System-Interface (ISI) but entirely outside the home country). These cases have not yet been tested, either in the FI-Swe-No project or in the Inter System Interoperability IOP test-cases prepared by TCCA.
Other nations
Looking to the future, in Northern Europe where there are countries with multiple open borders and very different languages, the operational complexity increases even if technical issues can be overcome. On 23 November 2017, the governments of Belgium and Luxembourg made a common declaration concerning, among others, an Inter System Interoperability programme between the two countries.
In 2018, the Benelux treaty on police co-operation will be upgraded, probably to give more capabilities to officers operating beyond their borders. This is essential, as without favourable legislation, the implementation of radio interoperability is much harder. Etienne Lezaack of the Belgian Federal Police says: “I am confident that these negotiations between Belgium and Luxembourg will be fruitful and ‘rapid’, thanks to our experience with radio interconnections (co-ordination groups between the police control rooms along a same section of border) and our acquaintance with our police partners at a technical level.”
Manufacturers
Motorola Solutions and Airbus have worked successfully on deployed Inter System Interoperability systems in the Nordics. Leonardo was a key contributor in the ISITEP programme. Hytera recognises that it will need to participate in future Inter System Interoperability projects and tells me that it is committed to the ETSI TETRA standard and it fully supports extension of customer networks by an ISI function. It also notes that the initial ETSI specification of ISI (ETSI EN 300 392-3-1) uses Q-Interface Signalling (QSIG) protocol based on Integrated Services Digital Network (ISDN) as a fundamental protocol. However, more recent and future-orientated approaches in the ETSI specification process highlight IP/SIP protocols as the next evolution of ISI. Hytera considers IP technology networks to be the right choice for flexible and comfortable integration. The company’s implementation of ISI follows the latest ETSI specification based on IP to optimise the value of ISI functionality for the customer and still be fully compliant with the ETSI TETRA standard.
Conclusion
It is not surprising that despite the work done in the ISITEP programme and the examples of Finland, Sweden, Norway and now Belgium and Luxembourg, general progress with Inter System Interoperability remains slow. Senior managers in the three primary emergency services will have national demands and problems to deal with, in a highly pressured and resource-limited environment, so working across borders may be considered ‘nice to have’ or too difficult. Progress will probably be made where a history of international incidents shows a clear need for such a project, coupled with the determination of a number of champions, some of whom were ISITEP programme leaders. We watch with interest how this will pan out in the next few months and years.
Getting started
Two Inter System Interoperability documents are highlighted here which can be used in the early planning of a project. The full set of published documents can be found here.
End-User Requirements Document
Understanding end-user requirements as early as possible is key to any Inter System Interoperability implementation, so this document describes the tools to capture them. The information flows are then identified, which leads onto the design of the technical, procedural and organisational solutions for interworking.
The document does not set out a prescriptive formula for implementation but prompts planners to take all of the different factors into account. It considers the group call requirements in terms of subscribers and connections, broadcast and individual call, and data messages. How will emergency calls be managed? The need for alert groups is highlighted whereby a user in a border region can quickly signal to users in the other nation that an incident is happening.
Subscriber and group migration issues are to be identified and included in the design as well as the connection of the networks. Any new features in the terminals will need to be identified and built into the programme with the manufacturers, and the document suggests a number of these for consideration. In
the same way, additional features in the Radio Console
are suggested.
Security is a major consideration. ISITEP Work Package 2.2 “Security Requirements” provides a description of the preliminary framework and methodology defined to carry out the development of the security requirements. The framework includes identification of the ISITEP system components and players that are relevant for the security analysis, and the definition of security objectives.
Draft Security Requirements
This document provides a framework for a joint team to identify their needs and design a security process matched to their particular Inter System Interoperability programme. Threats to the interconnected system may be very specific to the nations involved. The approach suggested is a security assessment, risk and vulnerability analysis, and finally a requirement definition. The results can then be combined into the programme from the start of the design stage.
The document also describes a possible regulatory and legal framework to be agreed between the two nations. Other aspects from the TETRA standards will need to be harmonised, such as authentication, air interface and end-to-end encryption, and terminal enable and disable.
