Telematics Transport Gateway for Telematics Systems. Independent on Mobile Networks

Transcription

1 Telematics Transport Gateway for Telematics Systems Independent on Mobile Networks Chul-Su Kim 1 *, Jongik Kim, Woo-Yong Han, and Oh-Cheon Kwon 1. Electronics and Telecommunications Research Institute, KOREA 161 Gajeong-dong, Yuseong-gu, Daejon, KOREA FAX: : , TEL: {chulsu1*, jongik.kim, wyhan, ockwon}@etri.re.kr Jin-Ho Song 2 2. UBIST CO., LTD. KOREA 7F Duwon B/D Sinsa-Dong, Kangnam-Gu, Seoul, KOREA FAX: : , TEL: kkrut@ubist.com ABSTRACT In this paper, we describe the telematics transport gateway which is an important part of the suggested open telematics system. We added more functionalities to the telematics gateway for more efficient management of sessions, protocols and services using various data transport protocols providing various telematics services simultaneously. Our telematics transport gateway gives service developers a transparent data transport method which enables them to use various protocol such as TCP, HTTP, SMS and enables them to develop service applications without knowing about an underlying mobile network technology and detailed methods. INTRODUCTION Many existing telematics systems have been dependently developed and provided on specific systems of a mobile network. We adapted the telematics gateway and framework [1] as an open telematics systems architecture to solve the dependency problems in our study. The suggested open telematics systems have client-gateway-server architecture to provide users with their services, in which data transport is a vital factor. It is necessary to support various ways of data transport methods considering the telematics services to improve the 1

2 quality of the services. However, it is a big burden for telematics service developers to understand various data transport methods fully and to implement them. With our telematics transport gateway, service developers and service providers can develop and provide services more easily and stably. Telematics service providers can use more than one transport protocols such as TCP, HTTP and SMS in one telematics service. When a service uses more than one transport methods, the service should maintain a service session. However it is not easy for service developers to write a service to maintain only one session using several transport protocols because it usually manage sessions on the transport layer. Therefore we put an application level session manager into the telematics transport gateway to solve the problem. In the suggested open telematics system which we adopted, the telematics gateway is placed between telematics terminals and telematics service servers. Telematics terminals connect to the telematics gateway to be provided services by many service servers. Therefore we put a service router into the telematics transport gateway to provide an efficient service management method. In the next section of this paper, we show the gateway and framework for telematics system which we took as an open telematics system. In the next section, we describe the architecture of the telematics transport gateway and its protocol. And in the next section, we show example services which was developed with the telematics transport gateway technology. And then finally we go to conclusion. THE GATEWAY AND FRAMEWORK FOR TELEMATICS SYSTEMS Many existing telematics server systems consist of server applications, a short messaging service center (SMSC) connection component, the related servers connection component, HTTP, and TCP/IP. The server application provide client applications in a vehicle with telematics services such as emergency service, remote door unlocking, and remote vehicle diagnostic service through the wireless application protocol(wap) gateway in a mobile network. If a telematics server system uses a WAP 2.0 gateway in the mobile network to provide services to telematics terminals, the services deeply depend on the mobile network. The services should be modified when they are deployed in other mobile networks. And the services should follow principles which mobile network providers suggest regardless service providers want to or not. To solve the problems, it has been suggested that the telematics gateway be placed in the system of service providers including the wireless optimized TCP, 2

3 the wireless optimized HTTP, the SMS Gateway, the Push Module and the Framework as shown in Figure 1. Figure 1. Telematics System independent on the Mobile Network The Gateway The gateway enables developers to write the telematics server applications which can be operated regardless of the gateway of the mobile network. It also enable developers to write applications without knowing about the interfaces of mobile networks which are related to the authentication and billing systems, and about details to integrate the related servers such as the E911 rescue server, the police reporting server and the traffic information distribution server. The Framework The developers can write applications without knowing about details to integrate the related servers distributed in networks using APIs which the framework supports. The framework supports various connection components which can connect telematics server applications into external related server applications. THE TELEMATICS TRANSPORT GATEWAY The telematics transport gateway manages data transport between telematics servers and 3

4 terminals through the Internet and mobile network. It has three gateways for data transport using TCP, HTTP and SMS, a service router which receives service requests from terminals and brings them to pre-registered service servers, and a session manager which manages session information based on services no matter which transport methods applications use. We developed our gateway trying to reduce redundant code. So, we defined some common gateway functions and the functions for TCP, HTTP and SMS separately and implemented all functions in one component with four blocks called Gateway Framework. Gateway Framework runs with some profiles which have lists of the functions and configurations for their protocols. Therefore, if Gateway Framework loads TCP profile, it works as a TCP Gateway and others do as the same way. Figure 2. Telematics Transport Gateway for telematics services Telematics Gateway Framework Telematics gateway framework consists of four blocks as depicted in Figure 3. Gateway common block is a set of interfaces which are used by all other blocks in common and should be implemented by other blocks. There are four kinds of interfaces in common function block, which are configuration interfaces to load and process configuration files and profiles, thread interfaces to use multi-threading environment and network interfaces to communicate with telematics terminals and servers. Service block is a set of modules which manages application level session, connections to distributed system, legacy systems and pre-registered services. Transport block is a set of modules which attach or detach the transport gateway header to data, manage an inter-operation with authentication and billing agent, and load profiles to set the gateway with them. Gateway service block takes the role of the communicator with 4

5 telematics terminals and servers. Configuration Gateway Framework Common Function Block Thread Network Session Information Service Information Service Block Session Transport Block Encode/Decode TCP Profile Content Auth/Bill HTTP Profile Service Server Service Gateway Service Block Profile Client Service SMS Profile Figure 3. The architecture of Telematics Transport Gateway with Profiles The Gateway Protocol for Service Router The gateway protocol is used to communicate service servers and terminals with the telematics gateway. Terminals and service servers exchange messages with the telematics gateway according to the protocol which can be processed by the gateway. The gateway protocol consists of header and body. Header includes the protocol version, service id, message type, terminal number and page information for segmentation and aggregation. Body includes actual message to be sent by servers or terminals. The gateway uses service ids and terminal numbers as keys to handle authentication and sessions. And it also uses service ids to determine that which service server should answer for the received message. Finally it uses message type to process billing and to determine if the session is closed. Octet Protocol Version Page Flag 2 Service ID reserved 3 Message ID 4 Message Type 5 Mobile Number 11 Current Page No 12 Validity Time 16+ Body Length End Flag Table 1. The gateway protocol header for service routing 5

6 Integrated Session The session handled by the integrated session manger of the telematics transport gateway is maintained during the life cycle of the service from the service server. With the integrated session management, seamless services are possible regardless of using various transport methods for a certain service. Figure 4. Integrated Session Session Model Life Cycle The session manager uses four session statuses to determine the start and the end of the service when the gateway receives service requests. The four session statuses and the meanings of them are followed. Session Invocation This status means that the gateway has received a request with an identifier meaning the start of the service. And then the gateway determines if it is a proper request through user authentication. If session information exists, the session manager will deletes the existing session information and change the status of the previous session into session termination using a query. Session Creation In a status of session invocation, if session information does not exist, the session manager 6

7 will create a new session and put session information into the session database. The session information includes session id, service id, the last query time for the session, authentication information, billing information, transport type, session status and so on. Session Query & Update The session information is created when a service starts and it is provided when there is a request querying the session information in the service. When service has ended, the session manager updates the last query time. Session Termination The session is terminated under following conditions. - The value of the timeout field of the session information exceeds the timeout limit. - The session manager receives a message meaning the end of the service - The session manager receives a request message with an identifier meaning service start and the previous session is not yet closed. TELEMATICS SERVICES DEVELOPED WITH TELEMATICS TRANSPORT GATEWAY Figure 5. The Telematics Services 7

8 We developed some telematics services based on the suggested open telematics system architecture with the telematics transport gateway to verify its usefulness, convenience, stability and so on. We put the telematics transport gateway under the processor of Worldwide Telematics Protocol which is a service application protocol defined by ETRI as a data transport component. We developed a push service using SMS and HTTP protocol and a mobile office service, an advertisement service and a POI service [2] using TCP protocol. CONCLUSIONS In this study we have developed the telematics transport gateway which has the following useful aspects. First, it provides services developers with a transparent data transport method which enables them to write applications without knowing about an underlying mobile network technology and detailed method. Second, it supports various transport methods such as TCP, HTTP and SMS, therefore developers can choose the best method for their services. Third, it has an integrated session management method which enables developers focus only on their service session regardless of which method they are using for data transport. REFERENCE [1] Woo-Yong Han, Oh-Cheon Kwon, Jong-Hyun Park, Ji-Hoon Kang A Gateway and Framework for Interoperable Telematics Systems Independent on Mobile Networks ETRI Journal, vol. 27, no. 1, pp , Feb., [2] Jong-Woo Choi, Woo-Yong Han, Chul-Su Kim, O-Cheon Kwon Open Telematics Services Deployment on the Gateway and Framework independent on Mobile Networks, Proc. of the 2005 international conference on wireless networks, pp , Las Vegas, USA, June [3] Yuka Gomi and Richard J. Weiland An Open Platform for Telematics, Proc. of the ITS World Congress 2005, Nagoya, Japan, Oct [4] North American Passenger Vehicle Telematics and Remote Vehicle Diagnostics markets Frost & Sullivan, Apr.,