Satellite-based Toll System

An electronic toll system that uses a satellite navigation system (GNSS) to determine the position of a vehicle on toll road and a mobile data network to communicate with the central system. This approach eliminates the need for special roadside equipment (RSE), such as toll gates. The payment may also be defined using more complex rules (e.g., charges based on entry, time or distance) and can be modified flexibly via software.

The toll charger wants to collect the toll for the use of road infrastructure that is subject to toll collection. The amount of the charge may depend on the type of vehicle, distance travelled, time of day, entry into the toll zone, time spent in the toll zone, etc. The toll charger prefers not to install toll gates on the charged infrastructure. The user (vehicle operator) wants the toll to be calculated and billed automatically without burdening the driver. The user is required to install an on-board unit in the vehicle that collects location information using GNSS in the given toll domain. The driver, according to the requirements of the toll charger, only specifies, for example, the number of axles on the vehicle if a trailer is attached or detached.

It is up to the toll service provider to decide whether to use an on-board unit with thin client functionality, which only measures position data in the given toll domain and sends it for further processing to the server, or an on-board unit with so-called thick client functionality, which directly recognizes the use of toll road and instead of position data sends further processed data, such as recognized toll sections, distance travelled on toll roads, or even the specific amount of toll charged.

Back office; Centre – server infrastructure collecting data from end devices; used by both toll charger and service provider

Charge Report – data structure sent from the Front End to the central system containing road usage and related information

Front End – device communicating with the central system; it may be just an OBU or OBU + proxy server

Contextual Data – dataset stored in the front end device defining toll charging parameters

Global Navigation Satellite System (GNSS) - global positioning system

Toll Domain; EFC domain – area or part of a road network where a toll regime is applied

Toll Transaction - an electronic record detailing a vehicle's passage through a toll section or on a toll road

On-Board Unit (OBU) - electronic device installed in a vehicle used in an electronic toll system

Toll Service Provider (hereafter “provider”) – entity that signs an agreement with the user, provides the OBU, and collects toll fees on behalf of toll chargers

Roaming Rules – part of context data specifying rules for transitioning between toll domains

Proxy Server – optional part of the front end device that completes data processing on behalf of the OBU

Roadside Equipment (RSE) – equipment located along the toll road

Thin Client – OBU that does not process the detected position data directly, but sends it to the provider's servers for processing

Thick Client - OBU that processes position data according to the toll domain definition in the context data

Toll Charger – entity responsible for a section of charge infrastructure and, via the provider, charges users for its usage

The user’s utilisation of the road is ensured through the on-board unit (OBU) installed in the vehicle. The OBU determines its position using a GNSS receiver and either sends the determined position for processing (thin client) or processes it directly and sends only the results of this processing (thick client). The data is transmitted to the central system via the public GSM network. Depending on the requirements of the toll charger, it also transmits data on the current status to the gate, or roadside equipment (RSE), for monitoring purposes via DSRC.

The OBU in thick client mode collects data based on a data file (context data - geomodel) defining the toll road (country, region, specific road, bridges or tunnels), which defines the charging rules, i.e. the data used to calculate the charge and the data that the toll charger requires to determine the toll to be paid. The data sent is referred to as a charge report. The toll road is usually divided into discrete areas where the same rules apply; these areas are called toll domains.

Fig. 1: Diagram of the Satellite-based Toll System

Roadside Equipment (RSE)

On toll road, toll chargers can install devices that communicate with passing on-board units for surveillance (CCC) or to inform the unit of its exact location in places where it is difficult to determine (so-called location augmentation). For this purpose, short-range communication devices (DSRC) located above individual lanes are used; these devices may also be mobile.

Contextual Data

The toll charger specifies the scope of the charged infrastructure and the charging rules for each toll domain separately. The charging rules determine 1. what is charged for (entry, time, distance travelled, use of a specific section), 2. the amount of the charge depending on the time of day and the type of vehicle, 3. what data is to be collected and sent to the charger, whether it should be geographical coordinates at regular intervals, the time of entry to the toll domain, identifiers of the road segments used, or just the amount of the charge in the given currency.

Furthermore, contextual data includes roaming rules, which are instructions for the on-board unit on what to do when toll domains intersect, whether to continue collecting according to the rules of one domain and at the same time start collecting according to the rules of the overlapped domain, or whether to suspend or terminate collection in the overlapped domain.

If the toll service provider uses a proxy server, it is possible that the contextual data is not stored in the on-board unit at all, and the calculation described above takes place on the proxy server. The on-board unit then only sends raw data from the GNSS receiver.

Proxy Server

The proxy server allows the use of OBUs with non-standard communication protocols, performing part of the data processing externally without changing the provider’s back end interface. The proxy is operated by the provider but usually supplied by the OBU manufacturer, as it closely cooperates with the on-board unit. It communicates using the OBU’s proprietary protocol and, where needed, completes the processing of the data, which it then hands over to the higher-level systems of the provider already converted into their standard protocol.

The principle of satellite toll collection is that the vehicle (or OBU) uses GNSS to determine its position, calculates the corresponding toll report using contextual data, and forwards it to the central system of the toll service provider, from where it is forwarded to the central system of the toll charger.

In the case of a so-called thick client, the contextual data is stored in the OBU, where the toll report is also calculated and then sent directly to the central system of the toll service provider.

In the case of a thin client, the OBU only provides location information and forwards it to a proxy server, which uses its contextual data to complete the toll report calculation and then sends this information to the central system of the toll service provider using a standardized protocol.

When determining the location in areas where GNSS is difficult to use, RSE can be used at toll gates, which allow (using short-range DSRC communication) the current location to be refined (so-called location augmentation).

Toll chargers can also use RSE on toll gates to monitor toll collection by obtaining control data on vehicle passages from the OBU via communication (using DSRC).

Communication between the Front End Device and the Provider’s Back End System

The provider first configures the on-board unit for a specific user and vehicle. This process is called personalisation.

Personalisation is not standardised, as well as service communication for software updates, on-board unit diagnostics and settings.

The front end device requests and update of contextual data when approaching a toll domain it doesn't have loaded or if it doesn’t have latest version of contextual data.

The main part of the communication is a regular transmission of the charge report, containing all data necessary for toll calculation.

Communication between the Toll Service Provider’s Back end and the Back End of the Toll Charger

The back-end systems of the provider and the charger communicate through many different interfaces. The provider updates the list of on-board units that are banned from entering the given toll domain (blacklist). The toll charger updates the context data for the providers.

The main part of the communication is the sending of charge reports from the provider to the charger, and the sending of payment requests from the charger to the provider, who then passes them on to the user. In toll domains where the charger wants to use tolling gates for toll collection and does not want to use the functions of autonomous units, they send the provider a list of toll transactions for confirmation, and the provider subsequently sends a payment request to the user.

Using control (supervisory) gates, the toll charger also sends the numbers of on-board units or vehicle registration plates of vehicles whose on-board units it considers to be non-functional. The providers then respond with information on whether the vehicle or OBU is in their databases and add, for example, the name of the owner. Once they confirm that the unit should be functional, they assume responsibility for the payment of the toll balance and any penalties under the SLA.

Communication between Roadside Equipment and On-Board Units

See entry Control mechanisms of EFC systems.

This is a common method of toll collection in many European countries. Most providers use toll on-board units, known as thin clients.

Autonomous OBUs (GNSS + GSM)

• • Definition of the application interface for autonomous systems – Charging (ČSN EN ISO 17575-1)
  • Definition of the application interface for autonomous systems – Contextual data (ČSN EN ISO 17575-3)
  • Vehicle tolling system architecture (ČSN ISO 17573)
  • Data exchange between providers and toll chargers (ČSN EN ISO 12855)

DSRC Interface

• • Application interface for dedicated short-range communication (ČSN EN ISO 14906)
  • DSRC interoperability: Application profile (ČSN EN 15509)
  • DSRC compliance checks for autonomous systems (ČSN EN ISO 12813)

Legal Framework

• • EFC Directive 2004/52/EC of the European Parliament „on the interoperability of European toll systems“

Parent group: Electronic Fee Collection

Subgroups: European Electronic Toll Service (EETS), DSRC Interface in Toll Systems, EETS – Interface Between Toll Service Provider and Toll Charger, Toll Domains and Toll Calculation Methods, Component Certification for EETS