Abstract
Communication architectures integrating vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications will be the key of success for the next generation of cars. Nevertheless, the integration of these communication partners in the same platform is a challenging issue because most of the literature is focused on individual parts, such as V2V routing protocols or specific safety services. The Walkie-Talkie project was proposed to fill this gap, focusing on the integration of V2V and V2I systems to equip vehicles with a set of intelligent services addressing safer, smarter, and sustainable driving. This paper describes the developed communications platform. The network design is based on IPv6 to support middleware and applications executed on both the vehicle and infrastructure sides. Whereas V2I is focused on the usage of IPv6 network mobility, V2V is provided by means of a hybrid solution based on intelligent delivery and delay tolerant networks. On top of the networking protocols, a service access middleware exploiting concepts from next generation networks is proposed, together with a proper on-board application management based on the open service gateway initiative. A prototype of the network and real evaluations are also presented as a proof of concept of our platform.
1. Introduction
It is increasingly apparent that, with the support of wireless communication, intelligent transportation systems (ITSs) will play a leading role in our society, where each automotive vehicle will be, in the future, a unique node in a global and ubiquitous vehicular communications network. These intelligent communication systems will support scenarios where the interactions within the vehicle, with the surrounding environment, and directly with nearby vehicles, will offer real-time communication among the thousands of cars daily crossing our cities and highways and opening new opportunities to many challenging applications dealing with security, management, and entertainment on the road. The Walkie-Talkie project (http://www.grc.upv.es/walkietalkie/) looks at the emerging intelligent transportation system environments and is aimed at analyzing challenges and offering solutions to enable safer, smarter, and greener transportation for the next generation of smart cars.
In the same way that communication between vehicles and infrastructure has been crucial for the success of current applications used in vehicular scenarios, where the best example has been the widespread adoption of the GPS technology, communication architectures integrating vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure-to-vehicle (I2V) communications will be the key to success for the next generation of smart cars. In fact, major automobile manufacturers, as well as public and private entities dealing with traffic management, are currently considering applications that require a high level of connectivity, including (a) active safety, accident detection, and traffic management applications, (b) smart route planning applications that will improve traffic efficiency, (c) fleet management and vehicle monitoring applications, (d) entertainment and comfort applications, and, more recently, (e) new services aimed at reducing the effects of CO2 emissions, thereby improving greener transportation.
These new applications depend on efficient vehicle-to-vehicle and vehicle-to-infrastructure cooperative communications, an area that so far is only evidenced in traditional radio data systems and traffic message channel (RDS/TMC) networks, as well as in the new e-call system. It is therefore mandatory to promote research in the field of vehicular networks based on technologies such as vehicular ad hoc networks (VANETs) in order to provide intelligent transportation systems integrated into “on-board” units, thus providing intelligent cooperative communication interfaces on the road. Towards this direction, the Walkie-Talkie project focuses on the integration of V2V, V2I, and I2V communication systems to equip vehicles with a set of intelligent services addressing safer, smarter, and sustainable driving.
The proposal presented in this paper covers two key points: (1) the integration of technologies and protocols for V2V and V2I communications in a common networking platform, and (2) the provision of a vehicular service framework ready to deploy new-age infotainment applications in the road domain. In order to cope with the previously mentioned aims, a comprehensive vehicular platform has been conceived in Walkie-Talkie, and the main findings are presented here, detailing innovative proposals in the areas of the following:
V2V communication, presenting a hybrid solution based on intelligent broadcast delivery and delay tolerant networks (DTNs). Infrastructure-based vehicular networks, on the basis of secure IPv6 network mobility. Service provision and management, through a remote service access middleware based on next generation networks and a proposal for local application management that uses the open service gateway initiative (OSGi). Experimental evaluation, by testing essential modules of the platform using a proper prototype.
This way, the paper is organized as follows: Section 2 overviews the most important previous works in the area; Section 3 presents the overall network architecture of the proposal; Section 4 details the vehicle-to-infrastructure communication subsystem, while Section 5 presents the V2V subsystem; Section 6 presents the developed service-access framework; Section 7 presents the developed network testbed and shows experimental results; and, finally, Section 8 concludes the paper.
2. State of the Art
Practical proposals for vehicular communications similar to the one developed in the Walkie-Talkie project are not frequent in the literature, due to the tough design and development efforts needed. For example, the work presented in [1] proposes an on-board solution for providing vehicular communications through an entity called “Car Gateway” acting as a mobile router. However, this solution is highly coupled with the vehicular platform, and it does not develop a generic communication stack to be instantiated on the different elements of an ITS network, as encouraged by the ISO/ETSI guidelines for the development of cooperative vehicular systems.
More related solutions can be found on recent proposals from field operational tests (FOTs) projects, since they offer the needed framework for implementing integral communication modules. In this sense, authors in [2] present the Drive C2X ITS station proposal, which integrates an OSGi-based software platform for applications and where communication issues are addressed at the network level. However, what is noticeable in this work is that IP networking has been left out, being UMTS-based communications only used for management and testing purposes. A similar contribution can be found in [3] where authors present some investigations developed in the context of the simTD project. More precisely, this work introduces a novel communication architecture providing enhanced security and privacy communications thanks to the use of a public key infrastructure. Nevertheless, this solution does not integrate IP communications.
Researchers have identified IPv6 communications as the key to ITS cooperative systems deployment [4]. Consequently, a combined solution for IPv6-based network mobility and security for noncritical vehicular services is necessary. The work presented in [5] follows this research line, presenting a solution based on V2I and V2V communications. Nevertheless, unlike the solution proposed by the Walkie-Talkie project, this contribution employs a constrained and nonautonomous communications stack that is used for experimental evaluation of specific routing and flow management subsystems.
In the particular case of V2V communications, also known as vehicular ad hoc networks (VANETs), extensive research has taken place in recent years [6]. These technologies, based on short-range communication radios such as IEEE 802.11p, support many different services and active applications between vehicles. Although many different unicast routing approaches have been proposed for VANETs [7], the Walkie-Talkie project does not forecast services and applications under pure unicast routing approaches. In contrast, due to rapid topology changes and frequent disconnection, we envision services taking advantage of routing approaches based on intelligent broadcast delivery for emergency and delay sensitive services and unicast routing approaches based on the concepts of delay tolerant networks to support noncritical services.
Regarding intelligent broadcast delivery, over the years several schemes have been proposed. In [8] we can find some of the most interesting schemes: counter-based, distance-based, and location-based. Note that all of these are based on inhibiting certain vehicles from rebroadcasting, reducing message redundancy, channel contention, and message collisions. In particular, they inhibit vehicles from rebroadcasting when the additional coverage area is very low. Additional efforts to find efficient broadcast delivery schemes can be found in [9–13].
When DTN proposals are considered, schemes can be divided in flooding and forwarding strategies. In the flooding family, each node delivers multiple copies of each message to other nodes, which act as relays, without using prior information about the network structure. Some examples of these protocols are presented in [14], such as Direct Contact (data transmitted in one hop), Two-Hop Relay, and Tree-Based Flooding. In epidemic routing [15], all nodes will eventually receive all messages, obtaining a maximum delivery ratio at the cost of consuming network resources heavily (channel, buffer, etc.). Algorithms in the forwarding family require adding some knowledge about the network that is used to select the best path from the source to the destination. The simplest approach is using a distance metric to estimate the cost of delivering messages between nodes (Location-Based Routing). Other more sophisticated schemes such as the Per-Hop Routing, where the forwarding decision is made by the intermediary node which determines the next hop, and the Per-Contact Routing, where the routing table is recomputed each time a contact is available, are presented in [16].
3. System Architecture
In the following we describe the Walkie-Talkie communications system architecture. First, the ITS network design is presented, identifying both types of ITS station nodes and communication patterns among them. Next, the general communication stack is presented, detailing the particularities that arise when it is instantiated on the different ITS station nodes.
3.1. Overall Network Design
The communication network envisaged in the Walkie-Talkie project covers V2V and V2I communications, as well as the interconnection between both subsystems. For this purpose, it takes into account three fundamental parts of networked ITS architectures: the on-board equipment of the vehicle, roadside units, and the remote service centre. The architecture follows the guidelines marked by ISO TC 204 and ETSI TC ITS, with the recent European Communication Architecture [17]. Figure 1 shows an overview picture of the developed communication network. Cars communicate among them using a V2V routing protocol or with infrastructure units using common Internet protocols over IPv6.
Overall architecture of the Walkie-Talkie communication platform.
Vehicles are provided with three key functions: gateway (GW), mobile router (MR), and host, as can be seen in Figure 1. The MR is in charge of performing routing tasks for V2I and V2V connectivity, so that the rest of hosts in the vehicle are not aware of the network complexity. A host could be a common IP-based smartphone or a tablet, which uses the vehicle MR to connect with the ITS network and the Internet. Finally, a GW entity is provided to connect with the various sensors available in the vehicles using the adequate protocols. In the Walkie-Talkie project, for instance, this entity is in charge of providing access to vehicle status information provided through the controller area network (CAN) bus. Similar to the communication architecture proposed by standardization bodies like ISO and ETSI [18, 19], there exists an in-vehicle network through which GW, MR, and in-vehicle hosts are connected, usually in the form of a WiFi access provided by the MR.
At the roadside, a set of roadside units (RSUs) are provided with a communications stack able to communicate using IPv6 and acting as an attachment point for vehicles using wireless local area networks (WLANs) based on technologies such as 802.11b/g (common WiFi) or 802.11p (ETSI G5).
The networking tasks of the RSU entity are performed by the access router (AR), whereas host functionalities allow the execution of any necessary application. Nevertheless, the host load of the RSU is expected to be much less relevant than in the vehicle and central sides, and this is the reason why these functionalities are expected to be integrated together with the AR. Additionally, since some RSUs can be connected with former road devices such as semaphores or variable message signs, a GW entity is also needed. In this case, a communications channel is also provided by using wireless sensor networks (WSNs). In particular, the Walkie-Talkie project envisages the use of IPv6 over low power wireless personal area networks (6LowPAN) to connect with special RSUs embedded in the pavement, road signs, and gantries.
The last key element depicted in Figure 1 is the central station, where services are hosted. Other important functions assigned to the central station are the maintenance of the IPv6 addressing of the vehicle and interfacing with the Internet offering IPv6 to IPv4 transition solutions, as it is explained in Section 4.
3.2. Communications Stack
According to the reference ISO/ETSI ITS communications architecture [18, 19], a reference OSI-based stack with four horizontal layers (access technologies, network and transport, facilities and applications) and two vertical layers (management and security) should be instantiated in the form of ITS station (ITS-S) nodes in vehicles, nomadic devices (mobile hosts), roadside units, and central systems. In the following we present such instantiation for the case of the vehicle, roadside equipment, and the road operator control centre. Figure 2 shows the main modules of the communication stack included in the three vehicles nodes, roadside AR and central station. Some nodes could instantiate the stack using more than one physical machine. This is true, for instance, in the case of the central station, as explained later on.
Walkie-Talkie vehicular communications stack.
The design shown on the top of Figure 2 shows the instantiation of the Walkie-Talkie communications stack in the vehicle, where the whole stack functionality is split in three nodes: host, MR, and GW, as introduced in the previous section. The MR includes the required functionalities to hide networking tasks to in-vehicle hosts. An unlimited number of hosts could connect with the ITS network by means of the access router through a common WiFi (e.g., 802.11a/b/g) or Ethernet connection. To maintain external communication with roadside equipment, control centre, and the rest of vehicles, the Walkie-Talkie platform currently supports the use of the following communication technologies: 3G/UMTS, common WiFi, 802.11p (ETSI G5), and 6LowPAN. Nevertheless, 802.11p is the most appropriate technology for V2V communications. IPv6 is used as a common network-level protocol for all nodes in the architecture, and the connectivity with the infrastructure is supported by the set of elements included within the networking and transport layer of the MR. V2V communication is enabled through another module which implements a hybrid solution based on intelligent broadcast delivery and DTN. As can be seen, IPv6 packets can be encapsulated in the V2V network using the proper VANET protocol. Finally, apart from the modules in charge of network operations, the MR is equipped with the elements required to secure communications. More details about the network modules for V2I and V2V communications are given in Sections 4 and 5, respectively.
The stack just on the left of the MR belongs to the vehicle host, which is in charge of executing user-level applications that could access remote services. This stack includes a common networking middleware based on the transport control protocol (TCP) and the user datagram protocol (UDP). An essential part of the host protocol stack is the facilities layer. A Java virtual machine (JVM) is used as the basis for the open service gateway initiative (OSGi) framework. OSGi acts as the lifecycle manager of both middleware parts and applications, simplifying the communication among software modules installed in the host. Above OSGi, another relevant facility is the IMS (IP Multimedia Subsystem) client, which is directly used by applications to access remote services in a normalized way, as explained in Section 6.
The GW communications stack is shown on the top right corner of Figure 2. Apart from the minimal functionality necessary to communicate with the rest of modules of the vehicles, it performs access and adaptation tasks for communicating with other vehicles subsystems, like the global navigation satellite system (GNSS), radio-frequency identification (RFID), inertial navigation system (INS), CAN bus, and odometry.
The communications stack instantiated in the roadside access router (lower right part of Figure 2) acts as a network attachment point for vehicles using short/medium-range communication technologies. Similarly to the MR, the available wireless technologies to communicate with vehicles are common WiFi, 802.11p (ETSI G5), and 6LowPAN. The AR could communicate with the central station using either an UMTS link or a common wired connection.
The last stack of Figure 2 is the one developed for the central station, on the lower left corner. Without loss of generality, we assume that this entity brings together the functionalities that are necessary at the road operator's control centre to maintain vehicle connectivity and support the infrastructure-based Walkie-Talkie services. The facilities layer now includes the necessary software to provide the IMS server-side capabilities for accessing services and hosting applications. These functionalities could be provided in a distributed way, using independent servers.
4. Infrastructure-Based Vehicular Communications
The network stack conceived by Walkie-Talkie includes a set of features enabling efficient communication between vehicle and infrastructure. In fact, this kind of vehicular communication is of paramount importance since it is in the V2I/I2V segment where novel traffic efficiency, comfort services, and relaxed safety applications can be initially tested and deployed due to the penetration issues associated to V2V communications. Furthermore, as has been acknowledged by the research community [4], communications based on the Internet protocol (IP) will be the key for successfully deploying future ITS applications, since it is a widely adopted protocol whose operation has been deeply verified. In particular, IP version 6 (IPv6) has enough addressing capabilities for being used in vehicular environments where potentially millions of entities (passengers, traffic lights, road sensors, etc.) will coordinate and exchange information.
For this reason, as depicted in Figure 2, the presented vehicular platform integrates the functionality necessary for establishing IPv6 communications. The following common IPv6 functionalities are supported by the communication stack regardless of the type of ITS node where it is instantiated:
IPv6 address autoconfiguration. One of the first tasks to be developed by ITS nodes when they connect to the IPv6 network relies on the acquisition of a valid IPv6 address. This process is supported by our communications stack using either stateless [20] or dynamic auto-configuration based on the DHCPv6 protocol [21]. IPv6 signaling. The basic operation of IPv6 requires nodes to support basic functionalities necessary during the establishment of IPv6 communications with other nodes. This is supported by the communication stack using the Neighbour Discovery protocol [22] and the Internet Control Message Protocol (ICMPv6) [23].
According to the ITS station reference architecture jointly standardized by ISO and ETSI, the Walkie-Talkie vehicular communications architecture is conceived to allow vehicle hosts to connect to the IPv6 network through the MR in a transparent manner. Therefore, apart from the aforementioned basic functionalities, MRs include additional features to support IPv6 reachability and session continuity of the in-vehicle network. More precisely, this feature is carried out by using network mobility basic support (NEMO) [24], a protocol that allows maintaining global reachability of the in-vehicle network while hiding the mobility tasks to vehicle hosts.
In NEMO, mobility capabilities are distributed between the MR and a new entity called home agent (HA), in order to maintain the IPv6 addressing for the mobile network. An unchangeable IPv6 mobile network prefix (MNP) is delegated by the home network to the MR for assigning addresses to the mobile network nodes (MNNs) that in our case are the vehicle hosts. Following the NEMO model, upon the reception of a router advertisement (RA) message from a roadside access router, the MR is aware of the existence of a new network. In this case, the MR, which already has a fixed IPv6 address within its home network (Home Address or HoA), generates a new autoconfigured IPv6 address within the new visited network. This address is called care-of address (CoA), and it is immediately notified to the HA. This notification is performed by the MR through a binding update message, which is acknowledged with a binding ACK sent by the HA. Only the MR and the HA are aware of the network change, since MNNs remain connected with the MR using the same address. Hence, when any node outside the home network (correspondent node or CN) communicates with any of the hosts connected in the vehicle, it uses the home address as destination, and, hence, packets follow the route towards the home network. Then, HA redirects these IPv6 packets to the current IPv6 CoA of the MR, which finally distributes the packets within the mobile network. In the same way, when packets are sent from any MNN to a CN, they are routed by the MR towards the HA, which forwards them to the destination. Hence, the HA and the MR perform an IPv6 into IPv6 encapsulation to create a mobility tunnel.
As described in Section 3.1, MRs are expected to maintain multiple network interfaces (802.11a/b/g, UMTS, etc.). In this scenario, the mobility experience offered by NEMO to vehicle hosts can be improved by enabling the MR to maintain network mobility across multiple interfaces. This feature is integrated in our communications stack by using the multiple care-of addresses registration (MCoA) [25] extensions, thanks to which the HA is aware that the MR is reachable through a set of CoAs.
The proposed vehicular communications platform not only supports the basic mobility management functionalities, but it also includes different elements to secure mobility-related traffic. More precisely, the provision of a secure mobile experience is achieved by means of the IP Security (IPsec) protocol [26], which is an enhancement to the basic IP protocol that defines a set of security services for protecting IP traffic. Since it is defined at IP level, the security protection is transparent to other protocols carried over IP like, in our case, NEMO and MCoA. Mobility traffic exchanged between MR and the HA is protected thanks to the establishment of an IPsec tunnel, thus providing both confidentiality and integrity. A mandatory step prior to the tunnel establishment consists in the negotiation of the so-called security associations (SAs) where both mobile router and HA agree on the set of security parameters (e.g., cryptographic algorithms or key material) to be used for protecting the mobility traffic. The Internet key exchange version 2 (IKEv2) protocol [27] is used for this purpose since it has been specially conceived to provide such functionality.
5. Vehicle-to-Vehicle Communications Approach
As anticipated earlier on, the Walkie-Talkie project bets on intelligent broadcast delivery for emergency and delay sensitive services and DTN unicast routing for noncritical services. In our scheme, vehicles operate in either warning or normal mode. Normal mode represents a default behavior; however, when a vehicle detects a dangerous condition, it will start operating in warning mode. Warning mode vehicles inform other vehicles about abnormal situations by disseminating warning messages periodically using the highest priority in the 802.11p MAC layer. We consider abnormal situations as any condition that could affect the traffic security and probably cause an accident, for example, slippery road, a previous accident where the involved vehicles are an obstacle for the normal traffic flow, works on the road, and so forth. Only messages representing these situations will be disseminated using the highest priority, while messages for comfort, entertainment, and, in general, noncritical applications, will be sent using lower priorities. Hence, normal vehicles use the DTN protocol, while warning vehicles use the smart dissemination delivery approach. Next, we briefly describe both communication approaches.
5.1. V2V Based on Smart Dissemination
In VANETs, intermediate vehicles act as message relays to support end-to-end vehicular communications. For applications such as route planning, traffic congestion control, and traffic safety, the flooding of broadcast messages might be considered a straightforward approach to achieve a widespread dissemination. However, if flooding is done blindly, broadcast storms may arise, with several disadvantages to the dissemination process [8]. For this reason, we propose the use of the enhanced message dissemination based on roadmaps scheme eMDR [28] to efficiently disseminate critical information in VANETs. Our novel proposal takes into account the effect that buildings have over the signal propagation to improve message dissemination in real urban scenarios. At the frequency of 5.9 GHz (i.e., the frequency band adopted by the 802.11p standard), radio signals are highly directional and will experience a low depth of penetration in urban scenarios. Hence, in most cases, buildings will absorb radio waves at this frequency, making communication only possible when vehicles are in line-of-sight.
In eMDR, when a vehicle starts the broadcast of a message m, it sends m to all of its neighbors. When any nearby vehicle receives m for the first time, it rebroadcasts it by further relaying m to its neighbors. To this end, every vehicle rebroadcasts m to the surrounding vehicles only when the distance between sender and receiver is higher than a distance threshold, or when the receiver is in a different street than the sender. We consider that two vehicles are in a different street when (i) both are indeed in different roads, or (ii) the receiver, in spite of being in the same street, is near to an intersection. This navigation information is obtained through a navigation system facility installed on the vehicle host, which is consulted based on the position calculated by the GPS receiver and accessed through the vehicle GW. Hence, warnings can be rebroadcasted to vehicles which are traveling on other close by streets, thus overcoming the radio signal interference due to the presence of buildings.
A formal description of our approach can be found in [28], where we demonstrate the offered benefits with respect to several previously existing proposals [8, 29, 30], when evaluating the performance of disseminating critical information in VANETs under realistic city maps.
An example of critical applications is the case of a service in charge of disseminating information about accidents. Figure 3 shows the information that our eMDR protocol will disseminate just after an accident takes place. This packet is encapsulated in IPv6 datagrams and then forwarded using our protocol. It includes the following information: (a) the time when the accident has occurred, (b) the location of the vehicle to determine the location of the incidence, (c) the characteristics of the vehicle and the profile of the occupants (for supporting emergency services in the assistance), and (d) accident details, such as the speed and acceleration of the vehicle when the impact occurred, along with the impact details. All these data help in determining the severity of the impact, making it possible to save lives, manage resources efficiently, and enable crashed vehicles to be removed from the site, restoring traffic flow quickly.
Essential information elements to be transmitted in case of accident detection.
5.2. VANETs as Delay-Tolerant Networks
Our previous approach based on broadcasting techniques is able to rapidly inform as many vehicles as possible, but it also imposes a heavy load on the channel. A delay tolerant scheme could be a solution for this, apart from being appropriate for those applications and services where notification delays are not critical.
Vehicles in a VANET are, typically, sparsely spread across the roadmap, creating time-varying clusters of nodes due to the distance between vehicles and the signal blockage due to buildings. This environment is subject to disruption, disconnection, and long delays. Hence, a complete source to destination forwarding path is not always available. Under these conditions, where only intermittent connectivity and opportunistic contact take place, we propose, for noncritical services, the use of DTNs to deliver data packets. DTNs allow sharing information even in the presence of high delays, and, when a route to the destination of a message does not exist, the message is stored and carried until a route becomes available (this is known as the “store-carry-forward” paradigm). Moreover, by having location information, the packet forwarding can be enhanced.
In the Walkie-Talkie project we propose the map-based sensor-data delivery protocol (MSDP), a DTN routing protocol that, using the digital cartography facility integrated in the MR stack, searches for the best next forwarding node. The novelty of our proposal is that, with the aim of efficiently delivering data packets, it bases its routing decisions not only on distance or directions but also on the programmed route of the node, the amount of data stored in the mobile router's buffer, and the trustworthiness of the data source. This way, it is mandatory that all vehicles maintain a certain degree of knowledge about their travel plan. The basis of the MSDP protocol is a utility index (UI). This index is used to make routing decisions, and it is based on several factors, such as the trustworthiness of the location, the time to reach the next node, and the transmission availability. In other words, a higher UI value indicates that the node is a better candidate to reach the destination. In fact, this destination tends to be an RSU, since one of the main goals of MSDP is the collection of information gathered from the road side in the RSUs.
Figure 4 presents a typical situation for MSDP, where dashed lines represent the movement of the nodes, while solid lines represent wireless transmissions. In this example, the sender node is
Typical situation for MSDP: dashed lines represent the movement of the nodes, while solid lines represent wireless transmissions.
6. Service Provision in Walkie-Talkie
The open services gateway initiative (OSGi) is a framework intended to facilitate the software management in Java environments. OSGi provides important advantages when deploying new applications, achieving software modularity and solving intermodule dependencies. In this framework, each application is implemented as one or more OSGi modules, called bundles, which are deployed together with extra meta-information attached in a manifest file. Among other data, this metainformation lists the exported packages (packages visible by other bundles) and the imported ones (packages needed for the current bundle). With this information, the OSGi framework manages the dependencies automatically. Thanks to this feature, it is possible to build a module hierarchy, from the most basic middleware to user applications.
Due to its numerous benefits, the OSGi framework has been integrated within the proposed communications stack to facilitate the management of ITS applications. In the following, we describe two relevant software modules that have been implemented above OSGi: the IP multimedia subsystem (IMS) and the human-machine interface (HMI).
6.1. IMS-Based Service Access Middleware
Nowadays different services coexist in the field of ITS, from a simple video call to an advanced service for traffic monitoring. Therefore, a common framework for the provision and access to these services is needed. IMS can be an efficient solution in this frame and existing works demonstrate its potential on the ITS field [1, 32]. For this reason, the Walkie-Talkie communications stack includes a service access middleware based on the 3GPP IMS, which is placed at the facilities layer. IMS is a next generation network proposal that provides mechanisms for session establishment and negotiation of capabilities between client applications and services. Although IMS provides a mobility solution at the service level, this capability has not been used since the communications stack already includes network mobility support for the in-vehicle network (see Section 4). Thanks to the NEMO protocol operation, each IMS terminal equipment (TE), included in the vehicle host, will have a permanent IPv6 address independently of the IMS domain in which the user is registered.
The process of host registration in the IMS domain and the subscription to a service is carried out by using the SIP protocol, which is the basis technology to support IMS. First, the TE needs to register in the IMS domain. This is carried out by an initial SIP exchange with the IMS core, located in the central station, indicating the identity of the subscriber, the authentication method, and the user credentials. Once the subscriber is registered, the TE is able to subscribe to IMS services by means of a new SIP transaction using the desired service parameters, for example, the quality of service (QoS) or the session lifetime. The IMS core entities forward this request to the corresponding SIP application server (SIP-AS), which decides whether it is able to accept these parameters. In this way, a negotiation is maintained between TE and the service edge. If the negotiation is successful, the service session is established and the data flow between the TE and the service edge executed in the SIP-AS starts.
6.2. Human-Machine Interface
When a graphical interface is used, as in the case of the vehicle host, another important resource to deal with is the screen and how applications can gain access to it in a homogeneous manner. For this purpose, and because of the several requirements that an HMI must accomplish [33], the Walkie-Talkie communications stack integrates a modular HMI service. This OSGi bundle shows a main interface in which all applications installed in the vehicle host are integrated. This service has three fundamental aims.
It is in charge of drawing interface objects for all the installed applications. Each application must define an XML description of its interface, which is provided to the HMI service as an argument to paint the graphical elements (buttons, labels, etc.). The HMI module provides the unique input/output channel with the user, and it is in charge of distributing interface information among all applications. The developed HMI provides accessibility tools to host applications, such as on-screen keyboard, speech synthesizer/recognition, and map capabilities. The map OSGi service integrated in the platform is powered by openstreetmap.org, whereas the speech synthesizer and recognition is based on the Loquendo API. This is used to give spoken alerts from applications, such as incoming incidences or asynchronous events, and recognize voice interface commands, in order to avoid distractions.
As observed in Figure 5(a), the main window of the HMI interface is divided into three key areas. First, the upper bar includes general functions, such as the name of the active application, the status of the voice synthesizer and recognition, or basic functions for controlling the host. The second main part on the interface contains the icons of the installed applications. In this case a couple of tools for the user are showed, although other applications are installed for speed limit, router planning, or incidence notifications. The on-screen keyboard is also available in a button placed on the lower right part of the window.
Screenshots of the HMI and applications running on the top of the communications stack.
Figure 5(b) shows the HMI interface when the application called “Integrated Services” is active. This application integrates a unique map view with information coming from incidence-based services that are subscribed. As can be seen, the HMI capabilities enable the integration of applications in a friendly and nondistractive way, showing a map with all notifications that are notified by the voice synthesizer facility.
7. Evaluation Experience
Although the usefulness of the vehicular networking platform has been validated at service level through a proper HMI and several reference applications, which have been presented in previous Section 6, an analysis of the low-level operation of the network is also necessary to test the correct operation of the essential platform modules. For this reason, a reference network testbed has been developed in Walkie-Talkie following the scheme provided in Figure 1 and using an implementation of the communication stack shown in Figure 2. For the moment, only V2I communications have been experimentally tested, since this type of communications is essential for accessing infrastructure services (like Internet), and, consequently, it is found to be of paramount importance in the short-term deployment of vehicular networks on real roads. Nevertheless, as explained in the conclusion section, the experimental evaluation of the V2V communication model proposed in this paper (described in Section 5) is an important future work item in Walkie-Talkie.
7.1. Testbed Setup
The set-up scenario consists of one vehicle (integrated by a host and an MR), one roadside station (AR), and the home central ITS station for the vehicle (divided into an HA and an IMS server). The hardware equipment and associated software used for each node can be found in Table 1. The testbed has been deployed at the University of Murcia, near the Faculty of Computer Engineering and taking advantage of the ring road that surrounds the campus. The MR is provided with three different types of communication interfaces. On the one hand, the MR can communicate with roadside units using 802.11b/g/n or 802.11p technologies. On the other hand, the MR can directly communicate with the central ITS through the 3G/UMTS network.
List of hardware equipment.
During the implementation and setup of the testbed we faced some technical problems. The first problem we encountered was caused by the use of IPv6 communications. Since the network infrastructure available at the University of Murcia natively supports IPv6, we could easily support IPv6 communications with roadside units through the 802.11b/g/n and 802.11p communication interfaces. Nevertheless, most of the 3G providers (including the used one) still offer IPv4 Internet. Therefore, to enable an IPv6 access to the central station through the 3G interface, we need to employ an IPv4 to IPv6 transition solution. In particular, we used the OpenVPN tool between the MR and the node acting as HA within the central ITS station.
Another notorious challenge is related to the securitization of the network mobility operation. The IPsec security associations (SAs) to protect mobility traffic (e.g., Binding Update and Binding Ack messages) should be established using the address assigned within the home domain, that is, the home address (HoA). This is necessary to allow these associations to survive upon a possible change of the locally assigned care-of address (CoA) when the MR performs a handoff. However, the IKEv2 SAs, which are used internally by the IKEv2 protocol to protect the IPsec association establishments, are created using CoAs as endpoint. Therefore, each time a handover occurs, IKEv2 SAs need to be re-established with the new CoA. To avoid this inefficiency, NEMO and IKEv2 need to cooperate to allow IKEv2 SAs to be simply updated with the new configured CoAs [25] and avoid the costly SA renegotiation process. Given that current software implementations lack such interoperation, we have developed an interprocess communication between NEMO and IKEv2 daemons to allow the former to keep the latter informed about new configured CoAs.
Finally, regarding the configuration of 802.11p equipment, we experimented the restrictive line-of-sight requirements of this communication technology that operates in the 5 GHz frequency band. In fact, this requirement provoked us to install the AR on edge of the building roof and opted by using a two-storey building in order to improve the communication when vehicles circulate under the AR coverage area.
7.2. Analysis of Results
The developed testbed has been used to evaluate the network operation using 3G (UMTS) and 802.11p wireless technologies. Global reachability of the in-vehicle network is achieved by using NEMO, whose operations are protected using IPsec and IKEv2 protocols. It is worth mentioning that MCoA extensions have been disabled in order to better appreciate the performance degradation caused by the handover. The roadside unit is connected on the top of the Faculty of Computer Science, and it has been installed to only give 802.11p coverage to a small stretch of a near road. A common vehicle mounting the on-board equipment is driven around the building at an urban-like speed between 20 and 40 km/h. When the vehicle is under the coverage area of the roadside unit, the MR automatically performs a handoff from 3G to 802.11p. In these tests the network bandwidth (measured in Mbps) through a TCP flow maintained at the maximum allowable speed from the vehicle host to a CN connected within the central ITS station network. This traffic flow has been generated with the Iperf utility (http://sourceforge.net/projects/iperf/) (version 2.0.4). The period of RA notifications from the AR is set to a random time between three and four seconds (to avoid RA collisions with possible nearby ARs). Additionally, the expiration time of the pair CoA-HoA used is set to 30 seconds in both the MR and the HA.
The results obtained are shown in Figure 6. As can be seen, the slow-start algorithm of TCP tries to adapt to the wireless medium during the whole test, affected by the mobility of the vehicle. The first handoff from 3G to 802.11p occurs at time 310 s (see Figure 6(b)) and the second one, from 802.11p to 3G, at time 445 s (see Figure 6(c)). At these moments the data rate is null for a while, due to the time needed to change the CoA used against the HA. Nevertheless, the connectivity gap is more evident in the second handoff, because 802.11p technology is preferred when both 3G and 802.11p technologies are present. The handover mechanism waits for a Router Advertisement received through the 802.11p interface, but, if it is not received, the CoA-HoA association timeout indicates that the 802.11p connectivity is over and the handoff to the 3G technology must be performed. Moreover, we can appreciate the quite better performance obtained while the 802.11p link is maintained, with peaks near to 6 Mbps. Between times around 100 and 200 s the high speed packet access (HSPA) channel allocation algorithm adapts better, since the vehicle moves near the UMTS base station. It can be noted that the performance of the 3G link is similar at the beginning and the end of each test because the circuit is circular.
Maximum bandwidth using TCP.
Considering the final results, we can confirm that network mobility and security modules perform efficiently under a real intertechnology handoff, the most difficult to accomplish. The communication stack operates correctly, maintaining the in-vehicle network connectivity and showing good performance results. Unless high-quality multimedia transmissions are required, the bandwidth results indicate that the data rate required by most of the traffic efficiency and comfort cooperative services can be covered.
8. Conclusion
This paper proposes a complete vehicular network framework where all the essential nodes in the vehicle, roadside, and central infrastructure have been designed, both in terms of the network architecture and the communications stack for each node type. Notice that both V2I and V2V communications are considered, maintaining IPv6 networking as the lowest common denominator. While V2I communications are based on IPv6 network mobility through NEMO/MCoA protocols to maintain the connectivity upon the change of network attachment point by the vehicle mobile router, V2V communications are achieved through a hybrid approach based on intelligent broadcast delivery and delay tolerant networks.
The whole network architecture is complemented with the necessary framework for offering infrastructure-based services to vehicles and deploying in-vehicle applications. IMS and OSGi are used for hosting remote services and managing the lifecycle of local applications on vehicles and roadside units, respectively. The middleware integrated in the facilities layer of the vehicle host and the central station include these capabilities, as well as other applications supporting software, such as a flexible on-board human machine interface for the case of the vehicle host. Moreover, essential modules of the networking platform have been prototyped and tested in a real environment. According to our tests, good performances are achievable in the V2I segment when using multiple communication technologies during vehicle handoffs across roadside access routers.
This work is framed within the Walkie-Talkie project, whose current tasks are now focused on extending the performance assessment of the whole architecture through a set of testing scenarios covering both V2I and V2V. To this aim, the collaborations with the current European projects ITSSv6 (http://www.itssv6.eu/) and FOTsis (http://www.fotsis.com/) are essential. In the short term, the immediate steps of the consortium include the extension of the experimental tested to support the V2V communication proposal. Additionally, further tests are also planned to analyze the network stability in terms of packet losses and the latency of uplink and downlink communication directions. In the long term, future work lines are focused on the contextualization of vehicles and infrastructure nodes for providing extended pervasive services to users and the extension of the platform to cover smart city environments, where additional infrastructure entities will be networked. Here, the synergy among vehicles, road infrastructure, individuals, and buildings will become the key of our future research.
Footnotes
Acknowledgments
This work has been mainly sponsored by the Ministry of Science and Innovation, through the Walkie-Talkie project (TIN2011-27543-C03), and partially by the European Seventh Framework Program, through the ITSSv6 Project (contract 270519), and the Seneca Foundation, by means of the GERM program (04552/GERM/06).