Managing the LTE Migration Part 2 – From Application Friction to Open Connectivity

Different kinds of applications (video, etc) are the main drivers for moving to mobile broadband. Here we typically pay attention to “bandwidth-driven” features like video – because in narrow-band environments these are simply not possible.

The community is also discussing how the current public safety user features, like group communications (MCPTT), traffic prioritisation, etc are mapped to the new network technologies. Introducing these core features as part of the communication standards ensures interoperability and development of a market and offering benefiting the users and vendors alike. Telling the difference between a “network feature” and an “application” will become more difficult (and actually less relevant).

When focusing on the relevant topics mentioned above, we easily miss the more simple, the more straight-forward, and in our opinion the much more fundamental and dramatic change to the world of critical applications.

Most “applications” have actually very little to do with high bandwidth, or even communications as such. Application value is created by enabling automatic and real-time exchange of information between users and systems and seamless end-to-end workflows.

The major change will happen because the obstacles for moving the Critical Communications users to a truly Digital Age are about to disappear.

Critical Communications Applications – Quo Vadis?

Fire brigade – Squad leader gives instructions, he used the Tablet Computer to plan the deployment

In this article, we’ll look at the migration from TETRA to mobile broadband from the applications perspective. To understand the difference, we’ll go through some of the major “application hurdles” in TETRA as we know them, and see how this will change. We will also explain why the application landscape is about to be turned upside down – all for the good of the user.

Cloud and Open Interfaces future

We are convinced that the “applications” also for public safety and other authorities will be deployed in a similar (although not the same) way as in the commercial world.

In the Cloud (private “authority clouds” or via open cloud, depending on the user organisation requirements)
Deployed via “app-stores” (to a part restricted sites)
Based on standard mobile operating systems
Based on IP
Able to benefit from new standard interfaces and APIs for information exchange developed by the user community, enabling end-to-end integration
Able to utilise data sources via the Internet in a secure and controlled way (e.g. Google-data)

This does not mean that the systems will be completely open. On the contrary.

It means that the deployment of applications for a user organisation will be close to as simple and can utilise similar distribution models as it is for commercial enterprises and consumers.

This will be facilitated by new kinds of services from the Critical Communications operators that guarantee that the security requirements are met. These models will reduce the “application friction” significantly for even very small user organisations. Large organisations will be able to use the similar models to build or source their own in-house closed application systems.

TETRA Application Friction

Today we’re using TETRA for a variety of data driven critical applications. Some of these are not necessarily considered as “applications” by the end-users but nevertheless that is what they are. Good examples are AVL (positioning), messaging and status reporting.

While critical and valuable the current TETRA applications are, the reality is that the application environment is limited and users need to make compromises in application capability. We look here at the following “sources of friction”:

Capacity and bandwidth
Proprietary systems and siloed market
Proprietary mobile devices
Accessories and connectivity

Friction 1: Capacity and bandwidth.

Any application deployed over TETRA simply has to be optimised for narrow-band, and the data limitation needs to be accepted.

A large majority of current TETRA data applications are actually based on short data and status messaging. This is a consequence of both the ultra-narrow IP pipe in TETRA, but also the extremely good performance of SDS for this type of use. SDS is very efficient from the network viewpoint, but on the other hand since SDS messaging is using control channels, we need to pay special attention to network traffic load and congestion control. A good example of this type of application is AVL, which is a major source of messaging traffic. Â In LTE, the real-time positioning information from even large fleets can be considered just marginal noise.

When the network bottleneck is removed, the capacity requirements will increase on the IT-platform side quite significantly. We’ll need bigger data centers for crunching all the information we’ll be able to collect.

Even though TETRA can be used for different data purposes efficiently, the lack of bandwidth is the key problem for applications in general. We want to be able to share more and richer information in real-time and for that purpose we need mobile broadband.

This problem will naturally to the large part just disappear. We expect sufficient bandwidth can capacity for demanding applications – the resilience just needs to be solved on the other side. We should not expect an “unlimited” capacity anyway, especially for services like uplink video. The public safety user’s traffic profile is so much different from a consumer that caution must be applied.

Solved!

Friction 2: Proprietary interfaces and siloed market

This source of friction is related to the first one. Since we’re not often able to use IP to communicate with mobile devices, we need other interfaces and APIs, and this is where the fun starts.

The only real standard for interfacing an application with TETRA is PEI (Peripheral Equipment Interface). This is the serial protocol between an application and a TETRA radio. This is OK for software installed in the end-user side. For the server-side, PEI does not scale since the traffic needs to be handled via radios.
To have sufficient capacity and to avoid air-interface congestion, the server side is typically connected to the TETRA Infrastructure via API gateways. These APIs are proprietary and although nowadays quite well productised by infrastructure vendors, still require specific expertise. In addition, gaining access to these APIs requires going through partnering, validation, certification and other types processes for the application to become a “good citizen” of the vendor-specific eco-system. This protects the customer’s against misbehaving apps, but also makes it more difficult to deploy new features for end-users.

From the customer viewpoint the end result is that integrating a fairly simple application to TETRA can be slow and costly. There may be products, even used in other TETRA networks but do they support my infrastucture? This raises the bar for small user organisations to deploy their own applications.

To be fair, we have to remember that things usually are the way they are for a good reason. Applications that have not been designed with controlled load and the narrow-band network in mind could cause control channel congestion in the network. From this angle the customers prefer a closed rather than an exposed system to guarantee control. When the infrastructure changes to LTE, this problem becomes less significant.

TETRA as a standard is pretty loose, defining mainly the air interface. The rest of the system structure (SWMi) is a black box that can materialise in multiple ways. For this reason, many interfaces for management and applications are not so well defined and understood as on the commercial 3GPP side. The interfaces relevant to applications have not been standardised in TETRA. This has contributed to the slow adoption of data applications.

IP connectivity between servers and field users with reasonable bandwidth will remove the need for proprietary APIs. In the hybrid phase, the new platforms may need to interface with TETRA still, so this will not happen overnight, but the problem will become smaller. IP will allow the user community to focus on defining more open interfaces for applications, allowing easier integration and interoperability. We hope that this will also make it easier to define “standard” applications.

Solved! (well, almost)

Friction 3: User terminals

TETRA terminals have limited user interface capabilities. The radios have not been initially designed for application use, so the ability to deploy customised applications and user interfaces is limited.

As the next phase will be based on smart phones and table platforms, we get rid of this limitation. The market for public-safety grade 4G terminals is emerging, and we hope that the openness of the operating systems from application development viewpoint will not be challenged by the customised, hardenened, stripped or otherwise special variants of e.g. Android (so we do not end where we started from).

Critical Communications devices and operating systems will have special requirements, therefore we will see “non-standard” devices. One major difference is that consumer devices depend on vendor specific cloud services (e.g. Apple and Google messaging infrastructures). These exist to provide a controlled way for different services to communicate with consumer devices (push). This will be an unsuitable approach for many security-savvy user organisations, and alternative methods need to be used. It is important that the community pays attention to this as otherwise a world of “open devices” but with proprietary features will be created.

Solved… (but let’s be careful not to mess this again, standards!).

Friction 4: Accessories and connectivity

Most field applications and workflows depend on accessories to be efficient. User experience is the key.

Mobile data devices (e.g. cameras, barcode/RFID/NFC readers, fingerprint scanners, etc.
Special equipment, e.g. medical devices, defibrillators etc.
Printers

These devices are widely available on the market, but connectivity is an issue. Bluetooth data support in a TETRA device is unfortunately rare. The most common use of Bluetooth is for wireless headsets and audio only. For applications, this means either an integrated device (-> expensive and hard to find) or cable connectivity (->limited suitability for mobile use).

In our experience this has been one of the main obstacles for deploying field applications over TETRA. The limited bandwidth, proprietary APIs, etc can be managed, but lack of suitable hardware is more difficult to solve. Due to the small and specific market, manufacturers are reluctant to invest in developing TETRA-integrated accessories.

When moving to device platforms based on mainstream technology, this problem will to a large extent disappear. The public safety users will be able to enjoy the wide variety of COTS devices designed for field use. Of course, many users are already doing that, but not via TETRA.