Communication Architecture of Vehicle Telematics: the Key to Maximizing Shared Fleet Availability

Central building blocks of a reliable vehicle telematics communication architecture

The communication architecture of vehicle telematics for shared mobility use is made of two levels. The first is the local level: the vehicle itself and the user on-site. The second level is global and includes all internet or mobile network enabled systems used by operators to connect vehicles for efficient fleet management. The clients’ experience and the success of the service depends on the best possible connectivity at both levels. Figure 1 shows the basic building blocks of a dedicated communication architecture for shared mobility services.

At the local level, the vehicle telematics device and on-board electronics exchange data (e.g., battery charge level and mileage) and commands (e.g., unlock the immobilizer) via the vehicle’s CAN bus. The user can also interact with vehicle telematics systems via Bluetooth or RFID to unlock the doors, for example.

Bluetooth and RFID for local communication and as a fallback solution

Bluetooth and RFID enable direct communications between vehicle telematics and the client through the operator’s app or an access card. Neither technology relies on the cellular network. In station-based carsharing especially, rentals often start or end in underground garages where no network is available. Users can still easily access their booked vehicles through their phone with BLE (Bluetooth Low Energy). After an authorized booking, the sharing operator provides a time-limited access token through the user’s phone for this purpose. The vehicle’s telematics unit checks if the access token is valid as soon as the user is close and tries to open the vehicle through the operator’s app. After successful authorization, the telematics unlock the door and deactivate the immobilizer.

Due to its low cost and power use, BLE is a reliable fallback solution for digitized access to vehicles. In addition, operators can connect further accessories via the Bluetooth interface of the telematics.

Personalized RFID cards can provide vehicle access to clients who do not use a smartphone. Users unlock and lock doors via RFID scanners connected to the telematics and attached to the inside of the windshield. Authorization is done via a whitelist stored locally in the vehicle telematics and managed by the sharing operator. Users need to be close to the car to access it via RFID, due to the system’s short range.

The early years of carsharing saw extensive use of RFID cards. Now that most users have smartphones with Bluetooth, only a few station-based carsharing operators continue to use RFID.

Mobile network technology is the basis of reliable connectivity

While local communication technologies can perform some basic functions, sharing processes still need reliable communication via the internet. Vehicle telematics devices include modems to use cellular networks for this purpose. They use this connection to exchange vehicle state values and driving data with servers. All user-initiated actions, such as unlocking the central locking system, requests and commands from the operator, or vehicle events updates go through this communication channel.

This requires a powerful telematics server that also provides an Application Programming Interface (API) for the operator to access the fleet. During cellular connection outages, all events must be temporarily stored in the flash memory of the vehicle telematics. The telematics deliver these events as soon as they can connect to the mobile network again. Both the mobile network connection and the API server must be highly reliable to ensure that the vehicle telematics system is always available in real time.

SMS vs. VPN

But there’s a snag when using cellular networks to address telematics via the internet. Only the end-devices (telematics) themselves can send requests to the server but they cannot be accessed over the network. Otherwise, a third party could easily access any end device via the Internet. Permanently maintaining the TCP/IP connection to overcome this limitation is not a viable option for shared fleets, as the telematics’ energy consumption would increase heavily.

Many connectivity solutions with a basic telematics system architecture use SMS to proactively access vehicles remotely. The sharing operator sends an SMS to the telematics of a vehicle that can be identified via the unique mobile phone number. After receiving this SMS, the telematics initiate a connection with the operator’s server. However, this extra step is inefficient and increases latency, so customers face longer waiting times.

A more efficient approach, that all INVERS clients benefit from, is to use a Virtual Private Network (VPN) between the SIM provider and the API server. Sharing providers can benefit from a firmware perfectly tailored to these requirements to access their telematics via API calls in real time. The communication between the API server and SIM provider is encrypted by the VPN to protect the telematics from third party access.

Vehicle telematics and a smart connectivity solution in a single package

In addition to the communication architecture used, the quality of the cellular network also determines accessibility to the vehicles. Its availability varies depending on the network provider. Worldwide roaming that allows the use of several mobile networks per country is one way to provide ubiquitous and reliable network coverage.

Multi-IMSI SIM cards also ensure additional reliability. These SIM cards have multiple identities (IMSIs) from different network operators so that, unlike normal SIM cards, a failure of one network can be tolerated.

Mobile network operators use different mobile communications standards and operate them on different frequencies. This adds work for sharing operators, who must take care of their fleet’s connectivity themselves and negotiate their mobile communications contracts individually. Expansion into new markets is made more difficult, as the operator’s chosen telematics may not be compatible with local standards and frequencies. Also, the selection of contracts and roaming packages for SIM cards involves a great deal of adaptation and coordination.

Operators should choose a technology provider that offers vehicle connectivity as a complete package, instead of just selling the hardware. This will give them more flexibility to shape their growth and respond to changes in demand on short notice. By outsourcing their vehicle connectivity, they can spend more time on differentiating their shared mobility offering and creating a unique user experience. Operators can also benefit from economies of scale of the existing network of its technology provider and established support structures. By choosing the right technology provider, they will also ensure the connectivity and maximum availability of their shared fleet.

Future-proofing telematics technology in shared mobility

To ensure that sharing operators can use their chosen solution for as long as possible, they must make sure that their technology provider’s vehicle telematics architecture and connectivity solutions support the latest mobile communication standard. We saw a great increase in data transfer rates when we looked at historical development in mobile technology. But unlike in consumer applications, it is not all about total data volume in shared mobility.

Vehicle telematics don’t require high data volumes; power consumption, cost, size, coverage, reliability, and delay time are more important. There are two standardized variants available as part of the fifth generation (5G) mobile network for such IoT applications: NarrowBand IoT (NB-IoT) and LTE for Machine Type Communication (LTE-M). Both mobile communication standards operate within existing LTE networks and are currently offered in more and more developed countries.

The transmission of telematics data via LTE-M and NB-IoT requires significantly less signal strength than via 4G LTE, 3G or 2G. In the future, this could enable carsharing in locations with traditionally insufficient cellular reception. LTE-M enjoys worldwide support of all LTE bands with a single LTE-M module, making expansion of shared mobility operations easier.

INVERS develops its fully managed telematics and connectivity solutions for maximum fleet availability and supports the best possible mobile standard. INVERS CloudBoxx includes an LTE-M module, making them future-proofed technology solutions for shared mobility. Contact us to learn more or check our other solutions.