Motivation for the NGTP Group
Historically, vehicle manufacturers have offered customers proprietary services and have been dependent on a single Service Provider (SP) for delivery of these services in a specific market. This supply chain inflexibility made it difficult for providers to gain economies of scale and advance their offerings.
A more open and standardized approach to delivering services has clear benefits for the marketplace, but previous standardization efforts focused on replacing existing protocols, rather than integrating them, which met barriers to adoption.
With the proliferation of new technologies (e.g., UMTS, Wi-Fi, VoIP), it is likely that future in-vehicle devices will access services using multiple methods and technologies. The NGTP Group concluded that the telematics industry would greatly benefit from a technology-neutral pattern to expand the options for delivering services. If possible, NGTP recommends using existing standards and technologies (see also the NGTP message format).
So NGTP provides the vehicle manufacturers a wider range of service offerings and service providers to cooperate with and the service providers have the possibility to sell their implemented services several times.
The NGTP Solution – Open and Adaptable Connectivity
NGTP (Next Generation Telematics Pattern) is a new approach for delivering over-the-air services to in-vehicle devices and hand sets alike, with the focus on open interfaces across the entire service delivery chain.
NGTP’s developers set the following six objectives:
- Provide a technology-neutral pattern and consistent interface and protocol for telematics services;
- Reduce barriers to collaboration and implementation;
- Enable adoption of new technologies as they come online;
- Support legacy systems for connectivity throughout the service life of a vehicle;
- Gain wide acceptance and encourage innovation through an open approach;
- Increase the value proposition for vehicle manufacturers, service providers, content providers, and motorists.
NGTP will enable vehicle manufacturers to use the best offerings from a variety of partners while maintaining a consistent driver experience. The new pattern will also allow service providers and content providers to sell the same basic services like session management or a voice/data matching to multiple vehicle manufacturers. Moreover, the NGTP architecture enables an easy integration of legacy systems, allowing older and newer vehicles alike to access new telematics offerings.
NGTP accommodates the EU’s pending eCall initiative, and the pattern’s open architecture will accommodate future industry trends.
In order to foster collaboration and innovation, the specifications that constitute NGTP are public under a Creative Commons licence. The NGTP Group will work with the telematics community to communicate the specifications and support testing and potential adoption of NGTP.
About NGTP 2.0
NGTP is neither a traditional standard nor a product. NGTP aims to provide a general reusable solution to a commonly occurring problem. In the software development community this is called a design pattern. This is why the use of pattern instead of protocol in the NGTP abbreviation more correctly describes the vision behind NGTP. Design patterns can speed up development by providing tested and proven development paradigms but at the same time be open and flexible to new requirements.
A standard is an established norm, a formal document that establishes uniform engineering and to achieve this very detailed specifications are required. Standards provide compatibility at the expense of flexibility. The NGTP Group believes that flexibility is more important and has chosen the pattern approach.
Since publishing NGTP 1.0 in January 2008, the NGTP Group established real world implementations based on the NGTP pattern and received a lot of interest from the telematics industry. There are two main reasons for publishing the successor of the 1.0 publication now:
- The implementation of NGTP based telematics services and the telematics technologies have further evolved. The NGTP Group wants to share the experiences and best practices to NGTP and incorporate them in a new version 2.0.
- The 1.0 documentation describes the architecture in horizontal “layers”. As the stakeholder are implementing NGTP in a vertical way (by building blocks), the NGTP Group decided to re-structure the documentation by explaining each building block with its interfaces. That comes in line with some changes in wording for an overall much more comprehensive documentation.
Therefore the 2.0 release is not a kind of new pattern but incorporates a new view on the pattern and some extensions. NGTP 1.0 is still a valid pattern. That means that all solutions built up on NGTP 1.0 require no or only minimal changes to comply the NGTP 2.0 specification. There is no kind of migration from release 1.0 to 2.0 necessary.
Changes from NGTP 1.0 to 2.0
- Organisational building block „TSP“ has been removed from architecture and replaced by infrastructure blocks „Service Handler“ and „Service Integrator“, because NGTP should provide a task-based (role-based) view and not an organisational view on the telematics architecture.
- The „Service Handler“ enriches the data for the „Service Integrator“ that is responsible for integrating the services with the help of Content Providers, Call Centres and so on
- Interface 6(a) connects to the „Service Integrator“ now (formerly: direct connection to Call Center). This is again due to the fact that NGTP does not want to define an architecture based on organizational responsibilities, but on tasks. The callcenter node in the NGTP architecture is to be seen only as the callcenter service, any callcenter application is provided by the service integrator. Of course a real callcenter can obtain both roles and provide its own application.. The interface has been renamed by „6“ as there won‘t be an Interface 6b any more (see next paragraph)
- Interface 6b has been removed as the „Service Integrator“, got and gets the content through Interface 7
- Interface 9 is reserved for additional other (proprietary) services or interfaces.
- The ASN.1 files have been re-structured in a common part, a dispatcher part and a service part.
- The common part includes general and reusable message structures that can be imported in other ASN.1 files
- The dispatcher files provide message structures for dispatching the messages between the interfaces
- The service part contains all application service data that are provided by an OEM
- The use of pattern instead of protocol in NGTP as the technically more correct term
- Term operations instead of methods, corresponding to the pattern concept
- Service Provider (SP) instead of Telematics Service Provider (TSP) to reflect the task-based view (in contrast to an organisational view) and the technology neutral connectivity for services
While the NGTP 2.0 pattern described here still focuses on voice based services, different patterns for other kinds of services, e.g. web-based data-only services, are already discussed in the NGTP group and will be incorporated in future releases of NGTP.