Proceedings of 15TH World Congress on ITS 2008
Design of Open Telematics Service Based on Open Gateway and Framework: A Service Bundle Approach to Provide an Open Telematics Environment Shing Tenqchen†, Yung-Kuei Huang1, Hsin-Hsun Huang1, Foun-Shea Chang1, Kluo-Yueh Chen1,Yu-Shin Chen†, The Institute of Ministry of Transportation and Communication, R.O.C. Asia Consultants Limited, No. 130, Sung-Shan Road, Taipei, Taiwan, R.O.C. † ChungHwa Telecom Labs., 12, Lane 551, SEC 5, Min-Tsu RD, Yang-Mei, Taoyuan, Taiwan 326 1
2 THI
Tel: 886-3-424-4535, E-mail:
[email protected] and
[email protected] Abstract In this paper, we propose a service bundle approach to provide an open Telematics environment. We developed an open telematics system based on the open gateway and framework which is independent on a specific mobile network and is interoperable with other telematics systems. We also follow an extended global Telematics protocol (GTP) for mobile office service which can provide a lot of services together for subscribed members.
the Internet and wireless channel as shown in Figure 1.
Index Terms- - open telematics service, open gateway, Framework.
I. INTRODUCTION
Telematics systems nowadays are independent on mobile infrastructures that deliver telematics services to service users. Thus, it is very expensive to deploy a telematics service in a certain mobile network into another mobile network. Hence, system developers should design their services in bundle together underling mobile network. The telematics terminal can not only be used for the telematics service from another telematics service provider, they should provide the total solution for customers. Thus, an open “Telematics gateway and framework” is a MUST for every system provider [Kim (2006)]. In this study, we use the extended Global Telematics Protocol (GTP) 1.x for mobile office services including address book, schedule manger, car care book and advertiser, and mobile office service system including a terminal and server system. BMW will promote it to be next generation Telematics Protocol (NGTP) to let car be a part of mobile networks. The service server enables the mobile office services for users to use the services in vehicles and also at home through
Fig. 1 The open telematics Service Based on Open Gateway and Framework [Source: MOTC-Mid-term Report(2008)].
To provide different types of service cycle, new Telematics Service Providers (TSP) will be created for future needs for different types of customers. Many existing Telematics server systems consist of server applications such as a short message service center (SMSC), connection component, the related server’s connected component, HTTP, and TCP/IP, etc. The server applications also provide client applications in a vehicle with Telematics service such as instant traffic conditions, emergency service, remote door unlocking, and remote vehicle diagnostic service through the
wireless application protocol (WAP) gateway and framework in a mobile network. In section 2, we describe Telematics Gateway and Framework that we adopted as an open architecture for bundle service in this study. The so-called Global telematics protocol (GTP1.x) is a fundamental basis to provide these bundled services. In section 3, we describe the mobile system for on-board-unit (OBU) with extended GTP for bundles service design. In section 4, we provide a System Architecture for Mobile Servers with Extended GTP for Bundle Services. In Section 5, we propose The Core Functions of Bundle Services for Traffic Information Platform. Finally, we conclude this
study with some of the service results. II. OPEN TELEMATICS SYSTEM BASED ON GATEWAY AND FRAMEWORK
The Telematics server systems using a WAP 2.0 gateway in the mobile network are to provide Telematics services to terminals through various mobile networks. The services should be modified to be become a bundle service products deployed in various mobile networks. The service should follow the framework scope of OSGi (Open Service Gateway initiative) as shown in Fig.2, which mobile network providers suggest regardless to what the service providers want it or not.
remotely installed, started, stopped, updated and uninstalled without requiring a reboot for users. The management of Java packages/ classes is specified in great detail. Life cycle management is done via APIs which allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly. 2.1 The Gateway The Telematics gateway enables developers to write the applications for Telematics server and can be placed in the system of service providers including the wireless optimized TCP, the wireless optimized HTTP, the SMS gateway, the push module. The Telematics system is independent on mobile networks in Figure3. The mobile networks could be 2G/3G/3.5G/4G networks.
2G/3G/3.5G/4G Networks
Fig. 3 Telematics system is independent on mobile networks [Source: Midterm report MOTC-(2008)]
Fig.2 OSGi website]
&
System-Layering
[Source:OSGi
The core part of OSGi specifications is a framework that defines an application life cycle management model, a service registry, an Execution environment and Modules. Based on this framework, a large number of OSGi Layers, APIs, and Services have been defined. Applications or components (coming in the form of bundles for deployment) can be
The Telematics gateway is suggested to be independent on network and services. The network independent enables developers to write applications regardless of the gateway of the mobile network. The service independent enables developers to write applications without knowing about the interfaces of mobile networks which are related to the authentication and billing systems, etc. In Figure 4, the vehicle is equipped with a Telematics terminal which he/she has a wireless cell phone (e.g. 3G/3.5G/4G) device to communicate with Telematics service servers and terminal has a client application for Telematics services.
Fig.4 Open Telematics Service System for Mobile Office Service [Source: Kim (2005)]. The Telematics service server system is based on Telematics gateway and framework enable service servers and telematics terminals have synchronous data. 2.2 The Framework The developers can write applications without knowing about details to integrate the related servers distributed in the network using Application Peripheral Indicators (API), which the framework supports. The framework supports various connection components which can connect Telematics server applications into external related server applications. Thus, the Telematics portal framework overview can be designed as the Figure 5.
2.3 Extended Global Telematics Protocol (GTP 1.x) The extended GTP defines a protocol, called GTP 1.x since 2003 from Europe, to exchange messages between a Telematics terminal in a vehicle and a Telematics service center. Telematics service developers and service providers can develop and provide Telematics services without dependency on devices and services carriers. NGTP defines 15 Telematics services for them. 2.4 Telematics Service bundle structure Telematics Service bundle structure is designed and shown in Figure 6 to have these functions: Separate bundle from bundle descriptor, For bundle, manage execution related files, libraries, and related resources separately; For bundle descriptor, use XML.
Fig. 6 Telematics Service Bundle Structure [Source: WTP1.0(2004)]
Fig. 5 Portal Framework Overview [Source: WTP1.0(2004)] The Telematics framework is also suggested to be transparency due to two reasons: (a) Software Design Key transparency It will let the developers write applications without knowing about details to integrate the related servers distributed in networks using the framework supported APIs. (b) Server Transparency The framework supports various connection components which can connect Telematics server applications into external related server applications.
Thus, the system architecture of portal framework is suggested to have the WAP architecture like Figure 7. Service Bundle descriptor can provide a service for searching service bundles in a portal framework or in other bundle repository system. It will check if the service bundle can be installed in a certain Telematics terminal. The protocol of TCP/IP vs. WAP is shown in Fig.8. In Fig.8, the designer can base on WTP protocol to exchange data for terminal and service server for interoperability with other telematics system. However, the mobile office clients and servers are more acceptable for most recent cases. Thus, one shall consider the more general cases for the Telematics Service Server. The extended GTP for mobile office is suggested to match the sync server with terminal, service server, and web server simultaneously. The synchronization of client and server are shown in Figure 9 for thread manager and network manager, respectively.
III. MOBILE OFFICE SERVICE SYSTEM FOR CLIENT OBU WITH BUNDLE SERVICE DESIGN
Fig. 7 WAP Architecture of Framework [Source: WTP1.0(2004)]
Fig. 8 TCP/IP WTP1.0(2004)]
vs.
WAP
Portal
The Telematics services on the on-board-unit (OBU) at the client side are primarily to combine the convergences of informations, services, services platform, outside vehicle services, inside vehicle services, and call centers to provide an integrated complete Telematics service systems as shown in Figure 10. The system architecture and human interface service module will be classified into valueadded service operators, traffic information center, content service providers, etc, via the communicational interface of ISP providers. All of the services platform will provide an instant traffic info, fleet management, secure info, parking info, via the call-center, machineto-machine, man-to-man, etc. The infoplatform system architecture of OBU is shown in Figure 11.
[Source:
Fig. 9 Mobile Office Client and Server
Fig. 11 The info-platform system architecture of OBU At the following, there are two design flows for different kinds of system services for instant traffic info as shown in Fig. 12. (1) Design Flow for Instant Traffic info
(Source: WTP1.0 (2004)) Fig. 10 A complete Integrated Telematics Service
At the part of instant traffic information, one may use the unified interface of traffic info center to obtain the real-time traffic info for broadcasting. The OBU equipment can be cell phone and use PUSH button to show ID number, Mobile number, GPS coordinate, request for service type, status report (accident, construction, traffic jam, …). These info will send to TSP. TSP will deliver related info to different division according to the service types.
IV. SYSTEM ARCHITECTURE FOR MOBILE SERVERS WITH EXTENDED GTP FOR BUNDLE SERVICES
Fig. 12 Design flow for instant traffic info. (2) Design Flow for Trailer Support and Road Condition Report In the trailer support and road condition report, when the platform receives an ASK request from OBU. After obtaining the customer ID, mobile number, GPS coordinate, classification of service request, and status report, the platform will send the request to contracted value-added venders to send the immediate trailer support and road condition report. The design flow for trailer support and road condition report is shown at Figure13.
The system architecture for mobile servers with extended GTP for bundle services shall consider the equipment and interface. At the equipment side, one shall consider three main frames: (1) System mainframe clusters, (2) Data Storage clusters, and (3) Data Server cluster, respectively. (a) System Architecture for Mobile Offices The equipments of system architecture can be classified into service provider’s servers, information storage servers, electronic-map servers, and info servers basically. The system servers were mainly designed to response for connecting with the front-end OBU via interface servers. Information storage servers were asked to record the communicational info, user’s basic info, service records, and system log, etc. The electronic-map (e-map) servers are responsible for the show map of the user’s request, transformation of GPS coordinates and geometrical map, point-of-interest (POI) map showing, etc. The info servers are equipped with connecting to external info resources, ISP venders, and informational collection (send and receive). The basic requirement of OBU info platform with interface is shown in Figure 14.
Fig. 14 The basic requirement of OBU info platform with interface (b) Service Provider Interface
Fig. 13 The design flow for trailer support and road condition report
The interface of service providers is shown in Figure 15. It can be classified into service user’s interface and manager user’s interface. At service user’s interface, it is responsible for handling data receive/send records and info records. At the front-end info, it includes positioning info, data request, data retrieval, etc. At external user’s services, it includes external data info handling and data recording. The external info includes the traffic info, traveling info, POI info, and content info, etc.
To the OBU platform, most of the services are asked by front-end device. The replying back and processing are executed by platform. However, it is possible for driver to ask for reply info from platform to emit a message to the front-end device like real-time instant traffic broadcasting as shown in Figure 18. Thus, the activator is driver. (d) Extended XML and GTP for Bundle Services
Fig. 15 Transmission and data processing (c) Info Transmission Format In the interface transmission of communication, the front-end OBU will ask certain information from input device. Thus, the data format shall be designed to have the information like e-map, instant traffic info, parking lot info, weather info, etc. The operational flow of information asks and reply is designed for system server to serve as the activator as shown in Fig.16.
At the platform of OBU, front-end devices and external services, there are many different kinds information formats needed to provide different services. Therefore, the extended message language (XML) is suggested to handle information packet to deliver, receive, and decode them. XML includes the parsed info and contains many bits. The marked label contains the storage layout, logical structure, and related description for document. V. THE CORE FUNCTIONS OF BUNDLE SERVICES FOR TRAFFIC INFORMATION PLATFORM
The core functions of integrated services bundles can include driving safety, traffic information, information security, and fleet management, etc. (1) Driving Safety
Fig. 16 Activator: System Server
Fig. 18 The Core functions of driving safety
Fig. 17 Activator: Driver
The service bundle is shown in Figure18. After analyzing that information, one can provide this information to OBU, handheld device, cell phone, etc. The bundle service of driving safety can include six major services: (i) Call for service center, (ii) Emergency help, (iii) Trailer support, (iv) Accident help, (v) Voice recording, and (vi) Trajectory recording services, respectively.
(2) Traffic Information The traffic info will provide the e-map of current position for user. Via the moving of OBU, the e-map will update its e-map, parking lot’s info, weather conditions and instant traffic contents as shown in Figure 19
The purpose of fleet management is designed to let the front-end device or OBU to link with the communication channel with all of the dispatched vehicles and to show all of the current conditions (include positions) to backend centers. Via the processing of back-end system, the owner will know all of the conditions of dispatched vehicles. Mainly, we have the four major functions as following: (a) customer’s setting, (b) alert conditions, (c) vehicle tracking, and (d) back-end fleet management. There is only one of the last services is shown in Figure 22 to save the space. VI. CONCLUSION
Fig. 19 The Traffic info is shown on OBU, cell-phone, or handheld devices. Information Security On the information security, one can use Triple DES to add security mechanism to obtain the most security environment. The security handshake procedure and user’s login account management are designed to execute the five steps of security check to establish a public key system as shown in Figure 20 and 21, respectively. (3)
In this paper, we propose a service bundle approach to provide an integrated service under open Telematics environment. We developed an open telematics system based on the open gateway and framework which is independent on a specific mobile network and is interoperable with other Telematics systems. We also follow an extended Global Telematics Protocol (GTP 1.x) for mobile office service which can provide a lot of services together for subscribed members with at least minimum four different kinds of bundle services. The core functions of integrated bundle services can include driving safety, traffic information, information security, and fleet management, etc, respectively. However, they are not limited to those items.
Fig. 20 Establish a Public Key System
Fig. 21 The User’s Login Procedure (4) Fleet Management Fig. 22 The Back-End Monitoring Functions
REFERENCES [1] Choi,(2005) J.-W., Han, W.-Y., Kim, C.-S., Kwon, O.-C., (2005/06). “Open Telematics Services Deployment on the gateway and Framework independent on Mobile Networks,” Proc. of the 2005 international conference on wireless networks, pp. 374-379, Las Vegas, USA. [2] GTP 1.0 Specification (2003), http://www.gtp.org. [3] Han (2005), W.Y., Kwon, O.-C., Park, J.-H., Kang, J.-H. (2005/02), “A gateway and Framework for Interoperable Telematics Systems Independent on Mobile Networks,” ETRI Journal, vol. 27, no. 1, pp. 106-109, Feb., 2005. [4] Kim (2005), C.-S., Kim, J. and Kwon, O.-C. (2005/11). “Telematics Transport Gateway for Telematics Systems
[5]
[6] [7] [8]
Independent on Mobile Networks,” Proc. of the ITS World Congress 2005, San Francisco, USA. Kim (2006), C.S., Kim, J.-I., Han, W.-Y., and Kwon, O.C. (2006/02). “Development of open Telematics Service Based on Gateway and Framework,” ICACT 2006, p. 13491352. Mid-term Report (2008/07), MOTC-IOT-97TDB003, CHTTL & MOTC in Taiwan. OSGi Framework Scope (2008), wikipedia website, http://en.wikipedia.org/wiki/OSGi. WTP 1.0 Specification (2004), ETRI, Oct. 2004 and 2007.
