Freedom to interconnect their TETRA networks via an common open interface would allow users a real choice of suppliers, argues David Taylor, of infrastructure supplier Rohill

Virtually all network solutions for professional mobile communications are based on proprietary system architectures. Although the air interface may be compliant with an open standard such as TETRA, the internal interfaces are not open for integration with products from other suppliers.

Users who require seamless nationwide coverage therefore cannot use equipment from multiple system suppliers. Instead, they must depend on a single supplier for all their TETRA network requirements. This results in a ‘vendor lock-in’ which unfortunately prevents system expansion, interworking between different networks and future migration to newer technologies.

Rohill’s ODINI initiative is an attempt to remove the barriers of closed system architectures. It allows interoperability between PMR systems, including TETRA networks, on the basis of open standards.

ODINI has been developed in close co-operation with end-users and independent system integrators. A large number of interactive meetings have been held with public safety agencies around the world to establish requirements and find possible solutions for PMR network interoperability. Without exception, all end-users have confirmed their need for open solutions.

Rohill’s development of ODINI has attracted the attention of major European partners. Through a European-funded programme referred to as Heterogeneous Networks for Public Safety (HNPS), the company has been able to develop ODINI as a real open standard with help from universities, industrial partners and end-users.

The objective of ODINI is to create an ecosystem of products and services in a multi-vendor environment. Its open architecture has been emphasized by publishing the draft ODINI standard as an open specification, and making the ODINI gateway software available as Open Source.

Users’ needs

Even multi-agency networks do not always provide interoperable communications. For example, security personnel or private fire brigades working on a private mobile radio (PMR) network cannot usually communicate with public safety officers working on a nationwide network, even where both groups use TETRA-based radio networks.

A second requirement comes from the need to integrate different networks of the same end user. Often, there is no interoperability or only limited interoperability between the PMR network, the data network (LAN, WAN) and the telephone network. This means that information available in the police station cannot be retrieved by the police officer on the street or in the car. The need might be met by installing an overlay mobile data network – but a higher-level integration based on middleware could solve the problem in a network-independent fashion.

As I have mentioned, vendor lock-in is another challenge experienced by end-users. Proprietary architectures do not allow interoperation with base stations and dispatcher workstations from other vendors. Although this particular problem is almost impossible to address, it is certainly possible to interconnect networks based on available system Application Programming Interfaces (APIs) in order to expand the coverage of existing networks.

Another practical problem faced by users is the inflexibility of existing infrastructure solutions to perform software upgrades step-by-step, to adapt a region-specific configuration, or to find solutions for redundancy in order to achieve high availability.

Limitations of ISI

The top-tier TETRA infrastructure suppliers promised to solve a number of these problems using the TETRA Inter System Interface (ISI), and after almost ten years of delays this interface is now completed as a TETRA Interoperability Profile (TIP).
The first phase of interoperability testing has been successful, but the ISI has some significant limitations. These include high cost, reliance on almost obsolete technologies (E1, Primary Rate ISDN), and the fact that it supports roaming, individual voice calls and SDS transfer only.
Group calls, relied upon by more than 80 per cent of users within the public safety user groups, will not be supported by ISI until a further phase of testing has been undertaken. No time-scale for testing of group calls has been announced.

Scenarios for interoperability

Identified below are three different scenarios for system interconnections. Not all of these scenarios may be applicable to all end-users. Whether or not they are relevant depends on the user organization and existing networks. Generally speaking, the earlier the user is in the process of planning and deploying a TETRA network, the more scenarios may be applicable.

Scenario 1: tactical patch This scenario can be interesting for two applications. The first, illustrated in the accompanying diagram, supports co-operation between public safety officers across a national border, or between neighbouring regions in a large country.
(中国集群通信网 | 责任编辑：陈晓亮)