contracts, Quality of Service (QoS) requirements of the used service, and security ... In addition, communication inside the car and to another cars have to be ... MYCAREVENT provides the roadside technician and the driver with mobile ...
Architecture of a Vehicle Communication Gateway for Media Independent Handover Guido Gehlen, Erik Weiss, Sven Lukas, Carl-Herbert Rokitansky, Bernhard Walke RWTH Aachen University, Faculty 6 Communication Networks Kopernikusstr. 16, 52074 Aachen {guge, erw}@comnets.rwth-aachen.de
1 Information
available at http://www.mycarevent.com
Internet
On Board Unit (OBU)
RA-Device (e.g. PDA)
VCG
OBD
Drivers Car
Fig. 1.
Roadside Assistant (RA)
Fixed Com. Gateway (FCG)
MobilitY and CollAboRative Work in European Vehicle Emergency NeTworks (MYCAREVENT) is an European Project of the 6th Framework Program [2]. MYCAREVENT aims at optimizing the European market for automotive services and repair. MYCAREVENT develops and implements new applications and services which can be seamlessly and securely accessed using mobile communication. MYCAREVENT provides the roadside technician and the driver with mobile communication following an ”Always Best Connected” (ABC) approach to facilitate the communication between the mobile users within a collaborative work environment.
…)
Vehicle communication is important for various applications, e.g. providing real time data for logistics applications, collecting floating car data, transmitting software updates, or transmitting live traffic and travel information. In addition, communication inside the car and to another cars have to be managed. The occupants of the car like to connect to the car infotainment system, e.g. in order to access the music repository to up- or download music files. Automotive service worker may like to connect using a wireless link the On Board Diagnostic unit of the car in order to read out fault codes or to run a detailed diagnosis. Vehicle-to vehicle communication is used among other things to enable security relevant applications.
II. R EQUIREMENTS FROM MYCAREVENT TO THE V EHICLE C OMMUNICATION G ATEWAY
MT S, WL AN ,
I. I NTRODUCTION
This work has been motivated by the IST-MYCAREVENT project. The project aims at developing an innovative system which utilizes the state-of-the-art technologies to support the mobile user and worker in this area of the After Sales Market of the Automotive Industry [1]. One of the use cases is to support the roadside assistants with advanced remote diagnosis services and interactive repair manuals, as well as to advice the drivers in case of an breakdown situation. A short introduction to the objectives of the project is given in the next section before the gateway architecture is presented.
(GP RS ,U
Abstract— Communication within and from a vehicle is a key function for various vehicle applications, like telematics, logistics, and traffic control applications. This paper describes the flexible and extendable architecture of a vehicle communication gateway which acts as a central communication device embedded in the vehicle and managing the in-vehicle, inter-vehicle, and vehicle-to-infrastructure communication. The focus of this paper is the vehicle-to-infrastructure communication, since this link is continuously changing due to the mobility of the vehicle. To enable a seamless access to the infrastructure (e.g. internet) the gateway autonomously switches between to the “best” available communication system at the current time and location. The “best” available network is selected from a list of all possible networks according to a user policy. The policy considers the user preferences, operator contracts, Quality of Service (QoS) requirements of the used service, and security requirements. The architecture is defined that flexible that arbitrary communication system can be aggregated either as local communication (short range) system or wide area communication system (long range). A prototypical implementation of the vehicle communication gateway has been developed which uses GPRS, UMTS, and WLAN as wide area communication systems and Bluetooth, WLAN, Ethernet as local ones. The paper presents the architecture and the prototypical implementation of this gateway, which has been motivated by the European Union founded IST-MYCAREVENT1 project.
MYCAREVENT Backend/Portal
Vehicle Communication Gateway (VCG)
DB
RAC
RA Vehicle
Exemplary scenario from IST-MYCAREVENT
The vehicle communication gateway (VCG) is predominantly a part of the road assistant (RA) vehicle infrastructure.
He should be able to connect easily any mobile device, like a laptop or a PDA to the gateway. The gateway should autonomously establish a secure connection to the service portal using arbitrary communication systems (GPRS, UMTS, WLAN, ...) according to a policy which is dependent on the roadside assistant’s contract, preferences, and QoS requirements. The secure connection from the car to the MYCAREVENT backend/portal is established between the vehicle communication gateway (VCG) and the fixed communication gateway (FCG) at the border to the MYCAREVENT portal local area network. This ABC network is realized using a secure communication “tunnel” between the VCG and the FCG, similar to a Virtual Private Network (VPN), with the extension that a seamless media independent handover has been realized without releasing the communication tunnel.
logic is implemented on the VCG, since all decisions regarding a handover has to be triggered by the VCG, even if a remote instance within the internet/portal is able to initiate through the VCG a handover. IV. M EDIA I NDEPENDENT H ANDOVER (802.21) In order to cope with the challenge of the heterogeneous radio access network, the Vehicle communication gateway implements the IEEE 802.21 specification. The IEEE 802.21 Working Group for Media Independent Handover and Interoperability are working on a standardized interface for interoperability and handover in heterogeneous networks.
III. G ENERAL G ATEWAY A RCHITECTURE The vehicle communication gateway is designed in order to cope with the permanently changing communication conditions. The moving network inside or around the car is static, the communication link from the car to an infrastructure (car-to-infrastructure) or to other cars (car-to-car) is changing rapidly. Fig. 3.
Vehicle Communication Gateway
MIH Reference Model accordant to IEEE 802.21
eth IP Manag. (MobileIP, VPN, …)
BT WLAN serial
NetworkBridge
…
GPRS Encrytion (IPSec) Authent. (VPN) Reliab.
UMTS Dynamic Media Selection
Secure tunnel
WLAN
DHCP QoS Routing
Fig. 2.
System Architecture of the Vehicle Communication Gateway
The focus of this paper is the concept of an extendable vehicle communication gateway and a practical realization of the media independent handover layer. The media independent handover layer is geared to the IEEE 802.21 specification [3]. The system architecture is depicted in figure 2. The vehicle gateway provides various short range communication devices enabling mobile devices to connect via e.g. Bluetooth or WLAN. The different networks are bridged and a DHCP server is handling the IP address allocation. In order to connect to the portal/Internet, arbitrary long range communication systems can be used, like UMTS, GPRS, and WLAN. The software architecture is designed with a plugin approach that enables at a later time the integration of new mobile communication devices without changing the core software of the gateway. The communication device specific plugin has only be implemented and deployed for the VCG, the FCG is independent from the radio access network (RAN). Most of the software
The basic concept of IEEE 802.21 is illustrated with figure 3. The main element is a sublayer between layer 2 (L2) and layer 3 (L3), which is refered to as “layer 2.5”. This layer provides upper layers the service access point (SAP) MIH SAP and uses different SAPs of underlying layers, like Logical Link Control (LLC), Medium Access Control (MAC), or Radio Resource Control (RRC). The MIH layer provides within the User Plane the service of a convergence layer, which can be used by the network layer without the knowledge about the actual communication system. Within the Control Plane, the MIH layer converts communication system specific commands from L2 into uniform MIH events, which can be used by the network selector to trigger a handover. IEEE 802.21 proposes to separate the communication between the MIH layer and upper layers using the services Event Service, Command Service, and Information Service. The Event Service thereby follows an asynchronous approach, whereas Command Service and Information Service are using a query/response mechanism. A. Media Independent Event Service The purpose of Media Independent Event Service is to indicate or predict state changes and transmission behavior of layer 2 data links. The direction of information flow through the protocol stack is from lower layers to the MIH layer (Link Events) and from the MIH layer to upper layer mobility and network selection functions (MIH Events).
The nature of events propagated by Media Independent Event Service is mostly advisory and not mandatory. Since the MIH layer operates above different media types and is supposed to be media independent, not all media types may support the same types of events. Therefore, events must be registered with lower layers. Link Events Registration describes the process of the MIH layer registering with the event source entities, while MIH Events Registration provides a means for upper layer entities to selectively receive events from the MIH layer.
A. Media Independent Handover (MIH) Layer The Mobility Management & Network Selector of the Vehicle Communication Gateway uses events from the 802.21 Media Independent Handover (MIH) layer. In figure 4 the MIH layer couples within the Control Plane to layer 2 functions of each specific communication system and within the user plane to the IP layer of each system.
Application
B. Media Independent Command Service Commands from upper layers (L3) to the MIH layer mainly control the behavior of lower layers (L2) by carrying the upper layer decisions to the local or the remote entities in the lower layers. Command services are separated into Link Commands and MIH commands and may be local or remote. For instance, the query of upper layers about the current connection state is supported by the Command Service. The response is information unit containing details about the current state of the respective link layer.
Mobility Management & Network Selector
TCP
UDP IP
MIH IP
GPRS
IP
UMTS
IP
WLAN
IP
DVB-T
C. Media Independent Information Service Information on link layer level are provided by the MIH Information Service. These information may include neighbor reports or link layer parameters like channel information and MAC addresses from all network points of attachment of heterogeneous network types in a geographical area. Considering higher layer services, information may be disclosed about e.g. access to internet connectivity or availability of VPN services. Generally, information transfer takes place over IP. In cases where an information server is the MAC peer of the wireless host, this is not strictly necessary, but no advantage would be gained by omitting IP. V. V EHICLE C OMMUNICATION G ATEWAY P ROTOCOL A RCHITECTURE The protocol architecture of the VCG is geared to the 802.21 Media Independent Handover reference model [3]. The MIH layer provides a convergence layer to various arbitrary link layer protocols, like GPRS, UMTS, 802.11 (WLAN), DVB-T, 802.16 (WIMAX). Currently implemented are GPRS, UMTS, and WLAN. The Mobility Management and Network Selector layer is using MIH services and provides the application layer a interface to control the behavior of the network selection. This layer is working in a tight coupling with the IP protocol. The address of this IP layer is the never changing virtual IP address of the communication tunnel endpoint. Thus, the application on top only uses the virtual never changing address of the tunnel endpoint. The following sections are explaining more in detailed the MIH layer, the Mobility Management & Network Selector layer, and the used Secure Layer 2 Multipath Tunnel Protocol.
Fig. 4.
Media Independent Handover Layers
The Network Selector function bridges the handover requirements coming from the application with the current condition of all available networks. The application provides policies including the QoS, security, reliability demands regarding the communication and contractual limitations. This policy will be translated in rule tables which take the actual communication devices of the gateway into account. The MIH Connection Controller evaluates these rule tables according to the triggers coming from the MIH layer. B. Mobility Management & Network Selector layer The decision about the used network is based on communication modes which the set of communication devices are providing at the current time and place. Each mode contains the technical details, like MAC address, frequencies, bitrate and contractual agreements, like the cost, the cost model, or the roaming agreements. A table of all conceivable modes (Basic modes) is correlated with service specific QoS parameters (throughout and delay), see figure 5. This process matches the required QoS parameters of the respective service to the available network modes. In figure 5 the QoS parameters for VoIP are depicted. VoIP requires a minimum amount of throughput and a maximum packet delay to operate in very basic version (limited voice coding). That means the usability of VoIP starts with those values but the user satisfaction increases with higher throughput and lower packet delay. Increasing the throughput and delay makes only sense until the VoIP-Service is fully operating and the user is satisfied, at this point a further increase is not necessary but usually also does not violate an optimal service.
The current communication modes which can fulfill the service requirements with a specific accuracy are listed in an ordered table, called Operation Rule Table.
.5
.5
Satisfaction User Satisfaction
1
1
1
User Satisfaction User
User Satisfaction User Satisfaction User Satisfaction
Table of All Possible Basic Modes
Service Definition for User Groupe X Service Definition for User Groupe X Example VoIP Service Definition for User Group X Example VoIP Example VoIP 1
1
1 .7
.7
.7
.5
Throughput Throughput Throughput
Delay Delay Delay
Scanning Processing - Threshold Creation - Sorting of Rules to use the Mode
Table of All Available Basic Modes Basic Database for Network Selection
Fig. 5.
Table of All (Ordered) Rules “Operation Rule Database”
Generation of Operation Rule Tables
From the ordered Operation Rule Table the communication mode with the highest priority is selected. If this mode is not or no more available, the mode with the next lower priority is used. The table of the conceivable modes is created from the contractual agreements with the network operators. This table could be changed in our realization via a Web or Web Service based interface. C. Secure Layer 2 Multipath Tunnel Protocol In order to enable a secure and seamless connection from the communication gateway to the portal/Internet a secure layer 2 multipath tunnel protocol (SL2MTP) is used. The mobile vehicle gateway establishes a tunnel to the fixed tunnel endpoint by using the SL2MTP. All IP packets from and to the actual communication device are encapsulated in UDP packets. A UDP encapsulation is mandatory in order to enable a communication tunnel also over network address translation (NAT) nodes, which are often used by network operators. These NAT nodes enable network operator to save public IP addresses by mapping many private to less public IP addresses. The UDP tunnel is secured against evil dropper by unforgeable checksums. An optional encryption of payload data can also get enabled. Depending on the selected service different level of reliability can be selected. For a realtime service like VoIP a retransmission of lost IP packets is not beneficial, since a small latency is more important than the integrity of the data. In case of non realtime services a retransmission within the SL2MTP can improve the performance by avoiding retransmissions of higher layers, like TCP. Payload data will be classified and lead to a specific ARQ-mechanism. D. Gateway Architecture The proposed design architecture of the gateway is illustrated in figure 6. The right part includes different wide area network devices, like UMTS, GPRS, WLAN, or even
a broadcast system like T-DVB. To enable a seamless communication “tunnel” to the portal, the IP packets of each communication device are encapsulated in UDP packets (UDP traversal mechanism). The core elements of the architecture are the Connection Controller and Mobility Management, the rule tables, and the table generator. The left upper block is optional if a differentiated services flag will be used to support QoS. The architecture is that flexible that additional communication devices can be easily integrated by writing a device plugin which is compliant to the MIH Connection Controller interface. VI. H ARDWARE AND S OFTWARE ARCHITECTURE In order to validate the proposed architecture the Vehicle Communication Gateway has been implemented on a development platform, which is a IBM T41p laptop. The target platform will be an embedded device which can be plugged easily in the vehicle and fulfills all requirements for an automotive device. The laptop have already a WLAN 802.11abg, Ethernet, and Bluetooth devices integrated. In addition, the laptop has been extended by an WLAN Access Point and a UMTS/GPRS PC card. The operating system (OS) Linux has been selected in order to easily migrate the software to an Embedded Linux system. The developed software is divided into the three daemons mincoc, minco, , netlink, see figure 7. The netlink daemon is responsible for controlling the communication devices. This software provides a consistent interface to all communication devices oriented on the 802.21 standard. The minco daemon provides a more abstract interface to query the possible communication modes, the status of the connection and to select a specific network, or to define the rule for autonomous network handover. There, the rule tables are generated and executed. The mincoc daemon is a command line interface to the minco daemon which accepts user commands and prints the results of the queries. These daemons are developed in the programming language C++. Each communication device is encapsulated by a software component (plugin) which provides an equal interface to the core software. This concept enables the extension of the software with other communication devices or arbitrary device, for instance WIMAX or GPS. A GPS plugin has been integrated in order to map measurement signal strength records of different communication devices to the position of the respective measurement. This enables the generation of a mobile communication map. In further improved versions of the gateway, this information could be used to proactive trigger a handover. In addition to the command line interface, a Web and Web Service interface has been developed. The Web interface enables to control the gateway with a browser application locally on the laptop or remote from a different PC. The
Fig. 6.
Media Independent Handover Layers
Management Applications (e.g. MINCOC)
CM-SAP
Connection Manager (alias MINCO-Daemon)
CC-SAP
Connection Controller (alias Netlink-Daemon)
generic device API
generic device API
802.3 plug-in
802.11 plug-in
Fig. 7.
•Access Points •Costs •Positions
…
generic device API
UMTS/GPRS plug-in
Costs /Provider
Software Architecture
Web Service interface is an XML based interface, which is controllable by exchanging Simple Object Access Protocol (SOAP) messages with a Web Service client application. A prototypical Web Service client on a mobile device has been developed which controls the vehicle communication gateway. VII. C ONCLUSION The paper has presented an architecture of an extensible Vehicle Communication gateway that is oriented to the 802.21 Media Independent Handover reference model. The gateway provides vehicles an “Always Best Connected” moving network. Within the vehicle the user can connect with his device via WLAN or Bluetooth to the gateway. The vehicle
gateway autonomously connects to the fixed gateway via the best available communication system at that time and places according to the QoS requirements of the service. The implementation has been realized on a Linux system, low level functions are implemented in C++ and a control interface in Java using the OSGi [4] framework. A Web And XML Web Service interface enable the control and management of the vehicle communication gateway. In further works, the network selection algorithms are further improved by location information and a priori knowledge about the heterogeneous network coverage. In addition, Vehicle-to-vehicle communication, satellite communication, and DVB-T could be integrated into the architecture. R EFERENCES [1] G. Gehlen, E. Weiss, and A. Quadt, “Service Oriented Middleware for Automotive Applications and Car Maintenance,” in Proceedings of the 1nd Workshop on Wireless Vehicular Communications and Services for Breakdown Support and Car Maintenance. Nicosia, Cyprus: RWTH Aachen University, Apr 2005, pp. 42–46. [Online]. Available: http://www.comnets.rwth-aachen.de/guge-pub.html [2] “Mobility and collaborative work in european vehicle emergency networks,” Published on the internet. [3] “IEEE P802.21/D00.01, draft ieee standard for local and metropolitan area networks: Media independent handover services,” Published on the internet, July 2005. [Online]. Available: www.ieee802.org/21/July2005 [4] “The osgi service platform - dynamic services for networked devices,” Published on the internet. [Online]. Available: http://www.osgi.org
