General Overview
Global telematics services require an interface between the telematics unit and the off‑board components for a world wide approach. In order to reduce the risks of incompatibilities, it is essential to make the interface to the TU stable. This leads to a new telematics architecture.
Figure 1 : NGTP approach of telematics subsystems and their interfaces Interface IF#1 – IF#7
This architecture offers maximum flexibility for the telematics business partners. The end‑to‑end architecture of the NGTP relies on existing industry standards, in order to increase standardization and reduce development efforts. Another significant benefit of this infrastructure is that it can also coexist with legacy solutions.
To describe the scheme above, it is necessary to examine the 3 primary components of the framework: the Telematics Unit (TU), the Telematics Service Provider (TSP) and the Dispatcher (DSPT), all of which are connected via standardized interfaces.
Telematics Unit
The Telematics Unit (TU) is typically integrated in a vehicle but can also be part of a personal navigation device (PND) or a mobile phone. The TU communicates over a wireless network with one dedicated Dispatcher. This is done via Interface IF#1 (TU-Dispatcher).
Telematics Service Provider (TSP)
The TSP delivers the actual service and acts as an integration point for all the systems that are needed to execute the service delivery. The TSP has two main roles: the first is to deliver voice and data services to the TU, and the second is to deliver content to a call center such as map-data and POIs. A TSP can be connected with several content providers and call centers.
Additional customer, contract and vehicle data may be needed by the TSP to complete the service. This data exchange is done by accessing a Customer Data Provider (CDP) via Interface IF#4 (TSP-CDP). The CDP is typically a system at the OEM. If the TSP has to handle the special requirements in terms of E-Calls it is connected to a PSAP via Interface IF#5. Interface IF#6a and IF#6b manages all communication between the TSP and a Call Center, while Interface IF#7 manages content delivery between the TSP and one or more Content Provider(s).
Dispatcher (DSPT)
The stability of the interface between the TU and the back-end is obtained by introducing the Dispatcher. The Dispatcher provides this stable interface (Interface IF#1) to the TU and dispatches the data and voice traffic between the TU and the respective Telematics Service Providers as a service switchboard.
The Dispatcher communicates over interface IF#2 (Dispatcher–TSP) with one or several TSPs. The Dispatcher interacts with the Provisioning Data Provider (PDP) via Interface IF#3 (Dispatcher–PDP) to determine the target TSP that delivers the required service. The PDP is typically located at the OEM.
The communication over interfaces Interface IF#1 to IF#7 in the NGTP framework can be broadly structured in three main layers:
- Application Services Layer
- Dispatching Services Layer
- Control Services Layer
Figure 2 : NGTP high level architecture and the interfaces involved by dispatching services
Application Services Layer
The NGTP Application Services Layer defines the protocol message structures that are used for implementing the application services use-cases between the TU and the TSP. The Application Services Layer consists of standard (generic) application protocol messages defined and supported by NGTP. The NGTP Application Services Layer may also be extended to support custom device-specific applications as well as features that may be unique to a specific TU and application service implementation.
The specification document for the application services layer is NGTP Application Services Layer Document. This specification document covers the aspects of the Application Services Layer over all interfaces (Interface IF#1 to IF#7), which are involved in the service delivery. Interface IF#1 and IF#2 details are included in the document section "TU application services". Interfaces IF#3 to IF#7 have their own document sections.
Dispatching Services Layer
The NGTP Dispatching Services Layer defines the protocol that is used to enable service dispatching in the DSPT. Service dispatching is the function that sets up communication between one TU and different TSPs depending on the service executed or geographical position of the TU. (The dispatching services layer essentially sets up the routing of voice/data between the DSPT and a TSP depending on the service, the TU location, and customer information).
The specification document for the dispatching services layer is NGTP Dispatching Services Layer Document. This specification document covers the aspects of the dispatching layer over interfaces Interface IF#1, IF#2 and IF#3, which are involved in dispatching.
These interfaces and their dispatching services can be found in the corresponding sub-chapters.
Control Services Layer
The NGTP Control Services Layer provides functions that are expected to be transparently available to the Application Services Layer and the Dispatching Services Layer. Among others, there are the following control functions: transport control, security (encryption / authentication), quality of service, bearer control or reliability.
The specification document for the control services layer is NGTP Control Services Layer Document. This specification document covers the details of the control layer functions over interfaces Interface IF#1 and IF#2, which are involved in the control.
These interfaces and their control services can be found in the corresponding sub-chapters.
For abbreviations and definitions click here.
