The protocol consists of three main parts. One of the key middleware is called Dispatcher, which serves as an effective connection between the vehicle mounted unit (TU) and the TSPs server.

NGTP dispatcher provides seamless TSP functions for vehicles:

1. Receive requests from the vehicle TU,

2. Then access the customer and configuration database of the car manufacturer to route the request to the appropriate TSP;

3. The voice and data of the TSP are then forwarded back to the vehicle.

How NGTP promotes flexibility:

1. The dispatcher provides a customized interface that allows car manufacturers to provide new services without having to configure specific vehicles.

2. Independent and open interfaces connect TSP with call centers, content providers, and public safety response points (PSAPs), allowing providers to interchange based on market demand.

3. The proprietary customer data resides in the customer relationship management system (CRM) of the automobile manufacturer.

This architecture provides maximum flexibility for business partners in remote information processing. The NGTP terminal-to-terminal architecture is based on existing industry standards to improve standardization and reduce development. Another important advantage of this structure is that it can coexist with traditional solutions.

To describe these domains, it is necessary to describe the three main components of the framework: the Telematics unit (TU), the Telematics service provider (TSP), and the dispatcher (DSPT), all connected through standard interfaces.

Telematics Unit

Telematics units (TUs) are typically integrated in cars, but can also be part of a personal navigation device (PND) or a mobile phone. The TU communicates with a dedicated dispatcher over a wireless network. See the interface IF#1 (TU-Dispatcher) shown above.

Telematics Service Provider (TSP)

TSP provides the actual services and serves as an integration point for all systems that need to perform service publishing. There are two main functions of TSP: the first is to publish voice and data services to TU; The second is to publish content such as map data and POIs to Call Center. A TSP can connect multiple content providers and call centers.

More customer, contract, vehicle data may require more services from TSP. This data exchange is through the Customer Data Provider (CDP), shown in the interface IF#4 (TSP-CDP) function shown above. CDP is a typical system in OEM. If the TSP has to process special electronic requests, it is required to connect to a PSAP (see interface IF#5, IF#6a, IF#6b) to manage communication between all TSPs and call centers, while the IF#7 interface manages content publishing for TSPs and one or more content providers.

Scheduler (DSPT)

By introducing a scheduler, the TU and backend achieve stable interfaces. The scheduler provides this stable interface (IF#1 interface) to the TU and distributes traffic data and voice between the TU and their respective TSPs as a service switch.

A scheduler communicates one or more TSPs through interface IF#2 (Scheduler-TSP). Scheduler Associated Data Provider (PDP) determines the target TSP through interface IF#3 (Scheduler-PDP) and provides the required services. PDP is usually located in OEM systems.

II. Protocol Structure of NGTP

he interface protocol for NGTP can be defined as three interface protocol layers:

1. Application Services Layer

2. Dispatching Services Layer

3. Service Control Layer

1) Application Services Layer

The application service layer of NGTP defines the message format for implementing application service cases between TU and TSP. The application service layer contains standard (generic) application protocol message definitions and message definitions supported by NGTP. The application service layer of NGTP can also be extended to support customizing device-specific applications and capabilities, even if it is the only use for a specific TU and application service.

The application service layer definition file is the NGTP application service layer file (NGTP Application Services Layer Document). This definition file covers all interfaces (from interface IF#1 to IF#7) that the application service tier involves service distribution. Details of interface IF#1 and IF#2 are contained in the file section TU Application Services. Interfaces IF#3 to IF#7 have their own file sections.

The NGTP service application layer is mainly described in this document as the purpose of remote information processing. It allows Telematics service providers (TSPs) to provide remote information processing applications. This work is mainly done through the core architecture interfaces of NGTP, IF#1 and IF#2.

The service application interface layer interface IF#3 of NGTP is the interface that provides application services.

The application service layer interface IF#4-IF#7 of NGTP can be seen in their respective sections, describing the data type (application layer API) of the data being transmitted, but there is no specification on what to do (no requirement for the use of the transport media or network).

Interfaces IF#1 and IF#2

A subsystem containing the appropriate information domain that invokes the operation of the subsystem's interface by sending a message. Messages for each application include an upstream or downstream business header before service data.

Interface IF#3

IF#3 is the interface between a dispatcher (DSPT) and a specification data provider (PDP).

Interface IF#4

IF#4 is the interface between TSP and Customer Data Provider (CDP).            

SP with this capability to find customers. The search criteria used by the TSP, such as the customer's name, vehicle type, license plate number, etc., are used to obtain relevant customer lists, customer IDs, names, vehicle data, etc.

GetCustomerData: CDP provides this functionality to TSP to obtain detailed customer data based on a unique identifier, such as customer ID or VIN. The returned data may include name, address, relevant person, relevant vehicle data, etc.

GetAllowedService: CDP provides TSP with this capability to obtain available services (such as VIN) for each node's identity.

Get Authentication Instruction: CDP provides TSP with this capability to obtain customer authentication information, such as "Ask Secret Questions" or "Ask Password".

Verify Authentication Data: CDP provides TSP with this capability to authenticate customers, such as remote services, by checking the answers to secret questions given by customers, and the result is either yes or no.

Interface IF#5

The purpose of interface IF#5 is to describe how information is communicated with TSP and PSAP (Public Safety Response Point). This interface is designed to provide information to PSAP so that they can effectively perform E-call rescue services.

Data from TSP through interface IF#5 is valid and will not be confused by the European E-all method because it attempts to create a minimum set of data (MSD) to be sent directly from the vehicle to the PSAP. Data from interface IF#5 will be a richer collection of data, including vehicle data, customer information and location service component data, which can be effectively provided to PSAP. PSAPs must have direct access to these collision data from the TSP. This document does not define or undertake any plans to provide this infrastructure to PSAPs.

There is a European initiative to regulate this interface. The European Commission has suggested that the European Union set itself a target to reduce road deaths by half by 2010. One suggestion for how to achieve this goal is to require that electronic calls be selected for all new car standards. The European Union approved the proposal on September 1, 2010. This work was driven by the eCall-driven organization as part of the eSafety Support Forum.

The eCall-driven organization defines a minimum set (MSD) of data required by the PSAP to ensure proper emergency resource allocation. (MSD is the data recommendation that will be sent directly to the vehicle from the PSAP above). ECall-driven organizations also acknowledge that the effectiveness of e-calls can be further improved by sending additional vehicle and personal information from TSP via interface IF#5. Recommendations for these additional data are currently being determined by a representative group of PSAP and TSP working in Europe.

This document considers the above recommendations for TSP and PSAP.

There are two alternative E-call processes:

1. From vehicle to PSAP via TSP and call center, via interface IF#5 ("NGTPE-call")

NGTP E-Call refers to E-Call arriving at a call center from a vehicle via DSPT and TSP and further to PSAP. This E-Call service includes data (location, collision data, etc.) provided by all TUs.

Non-NGTPE-call means that E-call will travel directly from the vehicle to the PSAP over the network. This E-call service may not include all the data that a TU can provide, but it includes at least a minimal set of data, such as where a location should be provided. Optional data can be sent to a parallel TSP, enabling the TSP to provide this data to the PSAP.

Functional model of interface IF#5:

1. Online Service Data Provider, RequestServiceData: TSP provides PSAP with this function to request service data online. Data requested for a service always returns data or error messages.

2. Service Subscription Provider includes the following:

Start Subscription: TSP provides PSAP with this capability to subscribe to a service's data. The PSAP provides the returned content in the message format defined by the service data.

EndSubscription: TSP provides PSAP with this capability to terminate a service data subscription.

VoiceCall Terminated: TSP provides PSAP with this function to notify TSP that the voice call has been terminated. PSAP returns a description of why the sound stopped, unexpected or not.

3.Service subscribers (ServiceSubscribeer) include the following two points:

Receive Service Data: When PSAP runs a subscription, PSAP must implement this function for TSP to publish service data.

HandleVoiceCall: PSAP provides TSP with this capability to request processing of an incoming call. PSAP will return the status of call handling.

Interface IF#7

Interface IF#7 is the interface between TSP and external providers.

Functional models include:

1. Online Content Provider

Content providers provide this feature to TSP without having to subscribe to online requests for content. This interface provides stateless online request/reply APIs for content. A request for content always returns content or an error message.

2. Content Subscription Provider

StartSubscription: Content providers provide TSP with this capability to start a special content subscription. TSP supports a content-defined message format such as service data.

EndSubscription: Content providers provide this feature to allow TSP to terminate a content subscription.

3. Content Subscriber

ReceiveContent: When TSP runs a subscription, TSP provides this capability to content providers to publish content. Content providers use this feature to push updated content to TSP

The service scheduling layer of NGTP defines a protocol for enabling service scheduling on DSPT (Scheduler). Service scheduling is a function that sets up communication between TUs and TSPs that depend on either service execution or the physical location of the TU. (Service Scheduling Layer essentially establishes the routing of sound/data, TU location, customer information between DSPT (Scheduler) and service-dependent TSP).

The service dispatch layer is defined as the NGTP service dispatch layer document (NGTP Dispatching Services Layer Document). This definition file covers the scheduling-related interfaces IF#1, IF#2, IF#3 at the dispatch level.

Interface IF#1

Interface IF#1 is the dispatch subsystem interface of NGTP;

Functional model:

1. Dispatch Vehicle Data Service Interface

These dispatch headers appear in the message when sent to the up direction (vehicle to back end).

Dispatch Vehicle Data Request: Each application message for a vehicle TU needs to be sent as a Dispatch Vehicle Data message payload. By sending DispatchVehicleData requests, the TU Scheduling Service Layer requires DSPT to publish the payload of the application service to the appropriate TSP.

2. Dispatch Sound Service Interface

DispatchVoiceCall: DispatchVoiceCall is used when the TU calls to the DSPT using a single sound.

3. TU Data Service Interface

These dispatch headers always appear in the downward direction (back-to-vehicle) messages.

Handle DispatchedData Request: In an application payload, the DSPT sends a request to process the dispatch data to the TU.

Interface IF#2

Interface IF#1 is the call subsystem interface of NGTP;

Functional model:

1. Dispatch Provider Data Service Interface

Create Event ID: Create event ID allows TSP to get an event ID from DSPT, which starts on the TSP side. For example, start a remote service from a call center.

DispatchProviderData: By sending a dispatch provisioning data request, TSP requires DSPT to publish application service data to a specific TU.

ReDispatchService: ReDispatchService provides TSP with a way to call another TSP service. One example is that TSP recognizes that a customer needs a different service than the call request. TSP creates a generic TSP-to-TSP service request message that contains the customer's requirements and dispatches it for rescheduling.

This feature leaf is used by the TSP to deny a service.

EndService: The TSP uses the End Service request to signal the DSPT and the service is terminated. DSPT can release the resources of all related services.

2. Dispatch Provider VoiceService Interface

Handle HandleVoiceCallTermination: This service enables TSP to notify DSPT when a voice call terminates.

3. Provider Data Service Interface

HandleDispatchedData: The TSP uses this service to request the data DSPT provided by the application that contains the payload and other information needed to process the application service data.

The service control layer of NGTP provides the expected ability to make the service application layer and service dispatch layer transparent. Among them, there are the following control functions: traffic control, security (encryption/authentication), quality of service (Qos), load control and quality reliability.

The service control layer definition file for NGTP is the NGTP service control layer file (NGTP Control Services Layer Document). This definition file covers the details of interface IF#1 and IF#2 related to control functions.

The control service layer interface IF#1 was created to hide the complexity of communication between TU and DSPT. It must be able to handle, for example, different types of bearers (for voice and data), security and transmission mechanisms. The complexity is that the effectiveness of the media delivered through the interface IF#1 may change over time. In addition, application services may have different communication needs. This is also the responsibility to control the service layer, always through the dispatcher DSPT communication, to achieve the concept of central dispatch.