# Providing Adapted Contextual Information in  an Overlay Vehicular Network

Authors: José Santa; Andrés Muñoz; Antonio F. Gómez-Skarmeta
Journal: International Journal of Digital Multimedia Broadcasting
 (2010)

---

## Abstract

Current vehicular networks are developed upon
commercial solutions based on cellular networks (CNs) or vehicular
ad-hoc networks (VANETs), both present in numerous
research proposals. Current approximations are not enough to
cover the communication necessities of several applications at
the same time, and they are not suitable for future vehicular
pervasive services. The vehicular network presented in this paper
fills the existent gap between solutions lacking in flexibility,
mainly supported by an infrastructure deployment, and those
highly local and distributed, such as sole-VANET approximations.
In this manner, an overlay communication platform which can
work over the CN basis has been designed and developed. This
architecture is complemented by an additional support of an
information system located at the infrastructure side. Moreover,
since most of the information received from current notification
services is not relevant for the driver, an additional subsystem has
been devised to provide adapted information to users. This has
been carried out by means of an ontology model which represents
users' preferences and contextual information. Finally, using a
whole prototype of the telematic platform, the performance of
this interring process has been evaluated to point out its impact
on the system operation.


---

## Body

## 1. Introduction

Vehicular networks are becoming essential for telematics services within the Intelligent Transportation Systems (ITSs) field. The usefulness of wireless data communications in vehicles is noticeable in current monitoring solutions, which help companies to manage their transport fleets. These systems are mainly based on a navigation unit and a communication channel, which is usually established through the cellular network (CN). These first systems have been, therefore, the starting point of vehicular communications. However, new generation services conceived for future cars need a more suitable communication platform to connect the vehicle with the environment [1]. Unfortunately, the solutions provided by the current research on this topic are highly case-specific in most cases. Ideally, a network should be used to connect vehicles among them and to the infrastructure, and it should cover all communication necessities of all possible services aimed at the vehicle or the road side [2].According to the current state of vehicular networks, connectivity requirements can be divided into vehicle to vehicle communications (V2V) and communications with the infrastructure, following a vehicle to infrastructure (V2I) or infrastructure to vehicle (I2V) pattern. Examples of V2I and I2V communication technologies can be found in monitoring systems, traffic information systems such as Radio Data System (RDS) or Traffic Message Channel (TMC), and electronic fee collection systems. The most extended technologies in commercial products which follow these communication patterns are CN, FM radio, and Dedicated Short Range Communications (DSRC). Regarding V2V solutions, vehicular ad hoc networks (VANETs) using WLAN (wireless LAN) and DSRC are the prevailing technologies, and they are mainly used in safety applications. These services use V2V communications to propagate messages over a network created by vehicles. VANET solutions fit satisfactorily in services which require a low latency to communicate with surrounding vehicles. However, they suffer from routing problems in long transmission ranges, where multihop techniques must be used [3]. In such situations an infrastructure access could improve the performance.Maintaining the driver up-to-date about potential collisions is considered as one of the main goals on vehicular communications developments. Although this kind of safety applications has practically received all the attention in the past, new technological improvements and the globalization of services offered in other environments have led to the consideration of new generation services for vehicles. Information provision systems such as meteorology, congestion, or repair services are only the first step. Thus, some examples of new information services for future vehicles are digital identification of variable road signs, provision of context-aware information about the traffic state, and reception of commercial or cultural information depending on the location and the user's preferences.The platform described in this paper works in this line, proposing an overlay vehicular network enhanced with context determination capabilities to provide adapted notifications to users. Section2 introduces the advantages of a hybrid vehicular network which integrates CN advantages using a decentralised approach by means of a P2P (Peer to Peer) technology. Section 3 relates this proposal to the current literature about overlay networks and context management in the vehicle field. The networking platform and the ontology-based contextual subsystem are then explained in detail in Sections 4 and 5, respectively. Section 6 describes the prototype developed to validate the enhanced platform, and Section 7 evaluates it in terms of the processing time needed to infer contextual information adapted to users. Finally, Section 8 points out the conclusions of this paper and it gives some future research directions.


## 2. Approximation

As stated in the previous section, both VANET and CN have valuable features for vehicular communications. VANET solutions offer reliable connectivity among close vehicles, due to the same cars create a scalable and cooperative mesh where each vehicle acts as a router. On the other hand, CN offers long range communications thanks to a direct connectivity to the Internet through an operator's network. This communication paradigm has two extra advantages: the unlimited rate of equipped vehicles, and the use of a proved deployed technology. Advantages of both VANET and CN approaches are combined in this paper so as to establish a starting point to integrate all the services they offer individually. By using a P2P paradigm over the cellular network, we obtain an architecture which takes advantage of the benefits in both approaches. P2P networks create a virtual decentralised architecture where individual nodes can communicate without knowing physical details about the underlying network. Latency limitations for close V2V communications are initially inherited from CN. A CN connection cannot match the latency times of VANET systems between nearby cars. However, new improvements point to CN technology as a valid carrier of vehicular transmissions for a wide number of services, and it can now be considered as a suitable complement to VANET approaches [4]. The UMTS (Universal Mobile Telecommunications System) technology has greatly increased data rates and reduced the end-to-end latency. The cost of the communication channel is also an important issue in CN. However, due to special agreements between operators and service providers, the cost of CN data connections is gradually decreasing.A V2V network allows vehicles to communicate and propagate information over a limited area. Such a strategy is useful to notify nearby vehicles about traffic hazards, road conditions, traffic jams, and other local events. However, a V2I link offers extra benefits. In this line, our proposal represents a step forward, using an infrastructure system to provide context-aware information to drivers depending on their preferences. Broadly speaking, the drivers take advantage of a global system capable of processing all the events received from the roadside. This system can give a global vision of the road network state, processing information from vehicles and roadside hardware, and performing monitoring tasks. Thus, it could be possible to notify vehicles about traffic problems which affect a long highway, send a warning message when forecasting a congestion, or report any pollution problem in an area, for instance. These examples are only some of the possibilities such a system offers by means of traffic data analysis and a combination of V2V and V2I communications, hence overcoming limitations of current traffic information systems like TMC.Information provided to drivers can also be adapted using such a system. (In this paper the words “driver” and “user” are indistinctly employed to refer the person who uses the system in a vehicle.) The architecture described in the next sections includes an inference process, supported by an ontology model, which adapts information provided to vehicles according to the driver's preferences. Drivers and road operators can modify the system behavior, and relevant points of interest (POI) can be notified to the vehicle, according to customized context rules. This service exemplifies the potential of infrastructure-based services, as a complement to V2V possibilities.


## 3. Related Work

The suggested proposal is based on an overlay network which works over the UMTS cellular network. Neither the use of overlay nor cellular networks in a general ITS communication platform are broadly treated in the literature. In [5] the use of overlay networks over the CN basis for ITS is defended, to solve deployment limitations which can be found in VANET solutions. In [6] a P2P approach is used in a vehicular network; hence vehicles are organized in dynamic communication groups to exchange PVT (Position Velocity Time) information. However, a method to interconnect these groups and provide a link with the infrastructure is not given. UMTS is considered as an appropriate communication technology for P2P in [7], but the adaptation of underlying protocols to mobility conditions is identified as a key issue. The JXTA technology [8], used in the communication platform of this paper, is considered in a sensor network over GPRS (General Packet Radio Service) in [9]. However, a special rendezvous node must be installed inside the operator's network, because GPRS does not support multicast. The communication architecture described in this paper has been evaluated using the HSDPA (High-Speed Downlink Packet Access) technology, which improves the overlay network performance and supports multicast. In [10], authors describe the implementation of a GPRS-based network to disseminate traffic information. These services are of special relevance in our proposal; hence, the implementation of the presented platform includes some of them. The form in which traffic events are disseminated in that work is similar to the group-based approach used in this paper. However, contrarily to [10], here it is not necessary to continuously track the position of vehicles in order to determine the ones to be notified about incidences. An evolved development of this concept is given in [11], where the MBMS (Multimedia Broadcast Multicast Service) is used to propagate traffic events inside service areas. The same idea is considered in the platform presented in this paper, but at a logical level through the overlay network.The integration of the vehicle in the traffic context is a new concept which has recently appeared in ITS. This is integration require not only a suitable networking architecture, which allows for V2I and I2V communications, but also a proper support of the remote infrastructure. In [12] a global architecture for processing vehicle information and disseminate traffic events is given. The system implementation is not included, but it considers the base cellular network as a good candidate to develop a primitive mechanism based on SMS (Short Message Service) to exchange information. A platform with an extended ubiquitous nature is presented in [13]. Here, high-level protocols used in the Internet, such as HTTP (HyperText Transfer Protocol), are used to provide ITS Web services. Nevertheless, it considers sporadic WLAN connections as Internet access, thus limiting the availability of the platform. In [2] a multipurpose system to provide contextual information to vehicles offers extended navigation capabilities to users, such as the current state of a specific road. The telematics architecture described in this paper uses ontologies to model the traffic environment and user's profiles in order to offer similar capabilities. In [14], ontologies are used to implement a common interface for road operators. This enables the implementation of  semiautomatic monitoring tasks. In [15] the ITS platform where ontologies are used is more general, and they are considered for exchanging information among different components of the architecture. This comprises an homogeneous method of sharing data. In [16] an ontology for modeling the vehicle concept is formally created, although the application field is quite specific. The work included in [17] describes the idea of modeling user's preferences by means of profile ontologies. This idea is also followed in our paper to adapt contextual information to the user's needs.


## 4. Networking Platform

The main goal of this paper resides in the development of a suitable networking platform for implementing ubiquitous services which span V2V, V2I, and I2V communications. These services are then provided to new generation vehicles in order to extend the applications offered in them. Figure1 shows an overall view of the architecture of this platform. The lower part of the diagram involves the P2P vehicular network, whereas the upper part illustrates the additional support of the infrastructure to provide contextual information.Figure 1
Overlay communication architecture and information processing system.Every vehicle drives along roads with service provision capabilities, and each coverage area and its associated services are registered in a global entity called Group Server (GS). The services considered in the system have an informative nature and exploit V2V, V2I, and I2V capabilities. Hence, they include safety services such as breakdown or repair notification services or tourism and travel information about the current place. The notification mechanism is carried out according to a publish/subscribe scheme, where vehicles subscribe to some services and receive asynchronous notifications.


### 4.1. Overlay Vehicular Network

As shown in Figure1, the entities involved in the overlay network communicate by means of JXTA or, directly, through TCP. Using a P2P network with JXTA technology, vehicles communicate between themselves and with the infrastructure. As previously stated, the communication technology used is cellular networks, by means of an Internet link through the operator's infrastructure. The geometrical information about every coverage area and its P2P communication groups is stored in GS. Thus, every service available in each area uses a P2P group, which limits the propagation of messages and it is changed when the vehicle enters a new area. Vehicles pass from one coverage area to another through a hand-off process aided by a navigation system. The vehicle uses a TCP/IP-based protocol to send a hand-off request to the GS, which replies with the P2P connection details and the geometry of the new area.Messages transmitted over the JXTA overlay network are routed through logical pipes, and they contain information about the source of the message, the type of event, and the payload. If a message is sent by a vehicle, the packet includes the current location and an integrity factor to bound the goodness of the computed position. When a vehicle which is subscribed to a service sends a message in this communication system, it is received by all the vehicles in the area which are also subscribed. This mechanism offers a V2V communication paradigm. However, it must be noted in Figure1 how an infrastructure entity, placed in every coverage area, listens to all events notified in the zone; this is the Environment Server (ES). Thus, ES is in charge of processing all the events sent in a V2V scheme, and besides it plays a forwarding role between vehicles and the infrastructure in a V2I communication scheme, but it does not communicate with other ESs. Because the ES is connected to the rest of the roadside hardware, it is able to send certain notifications to vehicles, such as “your speed is over the limit”, using a unicast mechanism. The communication between the roadside hardware and the ES can be physical, by means of a serial connection, for instance, or remote, using a wired or wireless network. Moreover, roadside devices could be part of the P2P network, if they have sufficient resources.Environment Servers are logical entities and, therefore, they can be installed on physical computers located at the roadside or executed in a remote server at the core infrastructure. As can be appreciated in the vehicular network design, scalability of the system is directly related to the deployment of service areas. Since these areas are virtual, it is only necessary to update the database of service zones to add or remove areas. Moreover, when physical Environment Servers are not needed, only a new instance of the software must be executed at the core system if a new ES is necessary. This choice, apart from reducing scalability costs, offers more flexibility and eases maintenance tasks.


### 4.2. Protocol Details

It is clear that several communication protocols are necessary to maintain the connection of vehicles with the network and route information messages properly. The different messages used in the vehicular network are described next.Table1 includes the messages exchanged between the vehicle (V) and the Group Server (GS). This communication is carried out by a message exchange over TCP, using the cellular network interface directly. The first process between these two entities is the communication management. An initial Area_Update_Query message is used by the vehicle for registering itself against GS. A Disconnect message serves for ending the communication. The roaming process uses the Area_Update_Query and Area_Update_Response messages. The first one is used when a vehicle detects the end of its current coverage area. In that moment, it sends a new Area_Update_Query message with its new location. GS replies with an Area_Update_Response. This message contains the available services in the zone and the P2P parameters to enable the subscription to them. When the user wants to use a defined service, he sends an Event_Subscription message listing the services in which he is interested. It is important to note that each service usually has a different P2P group in each area, in order to offer different communication groups.Table 1
Vehicle-Group Server communication.
ProcessMessagesSenderCommunicationArea_Update_QueryVManagementDisconnectVRoamingArea_Update_QueryVProcessArea_Update_ResponseGSEventEvent_SubscriptionVSubscriptionRegarding the communication between the Environment Server (ES) and GS, Table2 summarizes all the exchanged messages over TCP. The ES_Registration message is used by ESs to connect with GS. This packet contains the location of the ES and thus GS is able to search for the P2P parameters of all services available in the zone and reply with an ES_Registration_OK message. If any error occurs, GS sends an ES_Registration_ERROR. This packet includes the reason of the error. Since Environment Servers are static entities which may be connected during long time periods, they need to update their configuration periodically. ES_Registration_Update message performs this task, by requesting an update of the P2P parameters. GS answers with this area information by means of ES_Registration_Update_Response. The second group of messages is used in the message propagation process. Sometimes it is necessary to ensure that all vehicles near the problem receive critical events. The location of such incidences may be close to the border of the coverage area. Consequently, it is necessary to propagate the associated message to the neighbouring areas. In order to perform this task, Environment Servers listen to all events and use the Neighbour_Groups_Query message to ask for the neighbouring P2P groups for the service in question. GS replies with this information through Neighbour_Groups_Response. Now Environment Servers can forward the message to neighbouring areas.Table 2
Environment Server-Group Server communication.
ProcessMessagesSenderES_RegistrationESCommunicationES_Registration_OKGSManagementES_Registration_ERRORGSES_Registration_UpdateESES_Registration_Update_ResponseGSMessageNeighbour_Groups_QueryESPropagationNeighbour_Groups_ResponseGSFinally, Table3 includes the three messages used by services to send messages over the P2P network. These packets are sent using a JXTA unicast communication pipe. The first message in this table is Vehicle_Event. It contains information sent from a vehicle service edge. All vehicles located in the area along with the Environment Server receive these messages. Environment_Event messages are sent by Environment Servers. These are used, for example, in the message propagation method described previously. Messages Vehicle_Event and Environment_Event contain the following fields:Table 3
Vehicle-Vehicle/Environment Server communication.
ProcessMessagesSenderMessage  PassingVehicle_EventVEnvironment_EventESSpecific_Environment_EventES(i)
source: the vehicle ID, which is currently considered as the license plate number (Vehicle_Event), or the Environment Server identifier (Environment_Event), which is a unique string;(ii)
location: the GPS position of the sender entity, using latitude and longitude;(iii)
integrity: the integrity value of the position [18], indicating the reliability of the location calculated by the navigation system;(iv)
payload: The content of the message.The last packet listed in Table3 enables Environment Servers to send messages to specific vehicles, and it does not include any information about position (neither location nor integrity). This message is used in a service which provides contextual information adapted to user profiles, as described later in the paper.For the moment, privacy and integrity issues have not been considered in the different messages exchanged among the entities of the communication platform. Those messages sent over TCP could be secured using Secure Socket Layer (SSL) or Transport Layer Security (TLS). In the case of the P2P traffic, it is envisaged to use JXTA secure communication pipes, which use certificates to secure signaling and data packets.


### 4.3. Infrastructure Support

A complete information system at the infrastructure side has been developed in the platform. The distributed core storage manager system, represented by a dashed line in Figure1, is implemented by means of remote objects which are used by the rest of the infrastructure entities through Remote Method Invocation (RMI). By using these objects, ESs communicate with the core storage system, forwarding new events from vehicles and road hardware. The Internet Traffic Operation Server (ITOS) provides a Web access with a complete view of road events. To this end, ITOS analyzes the roadside information, accessible via the core storage manager. This Web application offers a differentiated access to users and operators, by means of an authentication stage. Operators, unlike normal system clients or users, have an administration account with management capabilities. Furthermore, any user of the Web application is able to check the state of the roads, at home or even using the on-board computer, via the Internet connection.From this architecture explanation it can be seen that information from subscribed services is sent or received by means of events. These come directly from other vehicles or from the infrastructure, via ES entities. Events from the roadside have a local scope, because they comprise context-aware information exchanged in a V2V pattern. Due to hand-offs between coverage areas, it is necessary for vehicles to receive important events of the new area they enter, which were previously collected from the roadside. ITOS carries out this task through a TCP/IP-based protocol, as Figure1 shows.


## 4.1. Overlay Vehicular Network

As shown in Figure1, the entities involved in the overlay network communicate by means of JXTA or, directly, through TCP. Using a P2P network with JXTA technology, vehicles communicate between themselves and with the infrastructure. As previously stated, the communication technology used is cellular networks, by means of an Internet link through the operator's infrastructure. The geometrical information about every coverage area and its P2P communication groups is stored in GS. Thus, every service available in each area uses a P2P group, which limits the propagation of messages and it is changed when the vehicle enters a new area. Vehicles pass from one coverage area to another through a hand-off process aided by a navigation system. The vehicle uses a TCP/IP-based protocol to send a hand-off request to the GS, which replies with the P2P connection details and the geometry of the new area.Messages transmitted over the JXTA overlay network are routed through logical pipes, and they contain information about the source of the message, the type of event, and the payload. If a message is sent by a vehicle, the packet includes the current location and an integrity factor to bound the goodness of the computed position. When a vehicle which is subscribed to a service sends a message in this communication system, it is received by all the vehicles in the area which are also subscribed. This mechanism offers a V2V communication paradigm. However, it must be noted in Figure1 how an infrastructure entity, placed in every coverage area, listens to all events notified in the zone; this is the Environment Server (ES). Thus, ES is in charge of processing all the events sent in a V2V scheme, and besides it plays a forwarding role between vehicles and the infrastructure in a V2I communication scheme, but it does not communicate with other ESs. Because the ES is connected to the rest of the roadside hardware, it is able to send certain notifications to vehicles, such as “your speed is over the limit”, using a unicast mechanism. The communication between the roadside hardware and the ES can be physical, by means of a serial connection, for instance, or remote, using a wired or wireless network. Moreover, roadside devices could be part of the P2P network, if they have sufficient resources.Environment Servers are logical entities and, therefore, they can be installed on physical computers located at the roadside or executed in a remote server at the core infrastructure. As can be appreciated in the vehicular network design, scalability of the system is directly related to the deployment of service areas. Since these areas are virtual, it is only necessary to update the database of service zones to add or remove areas. Moreover, when physical Environment Servers are not needed, only a new instance of the software must be executed at the core system if a new ES is necessary. This choice, apart from reducing scalability costs, offers more flexibility and eases maintenance tasks.


## 4.2. Protocol Details

It is clear that several communication protocols are necessary to maintain the connection of vehicles with the network and route information messages properly. The different messages used in the vehicular network are described next.Table1 includes the messages exchanged between the vehicle (V) and the Group Server (GS). This communication is carried out by a message exchange over TCP, using the cellular network interface directly. The first process between these two entities is the communication management. An initial Area_Update_Query message is used by the vehicle for registering itself against GS. A Disconnect message serves for ending the communication. The roaming process uses the Area_Update_Query and Area_Update_Response messages. The first one is used when a vehicle detects the end of its current coverage area. In that moment, it sends a new Area_Update_Query message with its new location. GS replies with an Area_Update_Response. This message contains the available services in the zone and the P2P parameters to enable the subscription to them. When the user wants to use a defined service, he sends an Event_Subscription message listing the services in which he is interested. It is important to note that each service usually has a different P2P group in each area, in order to offer different communication groups.Table 1
Vehicle-Group Server communication.
ProcessMessagesSenderCommunicationArea_Update_QueryVManagementDisconnectVRoamingArea_Update_QueryVProcessArea_Update_ResponseGSEventEvent_SubscriptionVSubscriptionRegarding the communication between the Environment Server (ES) and GS, Table2 summarizes all the exchanged messages over TCP. The ES_Registration message is used by ESs to connect with GS. This packet contains the location of the ES and thus GS is able to search for the P2P parameters of all services available in the zone and reply with an ES_Registration_OK message. If any error occurs, GS sends an ES_Registration_ERROR. This packet includes the reason of the error. Since Environment Servers are static entities which may be connected during long time periods, they need to update their configuration periodically. ES_Registration_Update message performs this task, by requesting an update of the P2P parameters. GS answers with this area information by means of ES_Registration_Update_Response. The second group of messages is used in the message propagation process. Sometimes it is necessary to ensure that all vehicles near the problem receive critical events. The location of such incidences may be close to the border of the coverage area. Consequently, it is necessary to propagate the associated message to the neighbouring areas. In order to perform this task, Environment Servers listen to all events and use the Neighbour_Groups_Query message to ask for the neighbouring P2P groups for the service in question. GS replies with this information through Neighbour_Groups_Response. Now Environment Servers can forward the message to neighbouring areas.Table 2
Environment Server-Group Server communication.
ProcessMessagesSenderES_RegistrationESCommunicationES_Registration_OKGSManagementES_Registration_ERRORGSES_Registration_UpdateESES_Registration_Update_ResponseGSMessageNeighbour_Groups_QueryESPropagationNeighbour_Groups_ResponseGSFinally, Table3 includes the three messages used by services to send messages over the P2P network. These packets are sent using a JXTA unicast communication pipe. The first message in this table is Vehicle_Event. It contains information sent from a vehicle service edge. All vehicles located in the area along with the Environment Server receive these messages. Environment_Event messages are sent by Environment Servers. These are used, for example, in the message propagation method described previously. Messages Vehicle_Event and Environment_Event contain the following fields:Table 3
Vehicle-Vehicle/Environment Server communication.
ProcessMessagesSenderMessage  PassingVehicle_EventVEnvironment_EventESSpecific_Environment_EventES(i)
source: the vehicle ID, which is currently considered as the license plate number (Vehicle_Event), or the Environment Server identifier (Environment_Event), which is a unique string;(ii)
location: the GPS position of the sender entity, using latitude and longitude;(iii)
integrity: the integrity value of the position [18], indicating the reliability of the location calculated by the navigation system;(iv)
payload: The content of the message.The last packet listed in Table3 enables Environment Servers to send messages to specific vehicles, and it does not include any information about position (neither location nor integrity). This message is used in a service which provides contextual information adapted to user profiles, as described later in the paper.For the moment, privacy and integrity issues have not been considered in the different messages exchanged among the entities of the communication platform. Those messages sent over TCP could be secured using Secure Socket Layer (SSL) or Transport Layer Security (TLS). In the case of the P2P traffic, it is envisaged to use JXTA secure communication pipes, which use certificates to secure signaling and data packets.


## 4.3. Infrastructure Support

A complete information system at the infrastructure side has been developed in the platform. The distributed core storage manager system, represented by a dashed line in Figure1, is implemented by means of remote objects which are used by the rest of the infrastructure entities through Remote Method Invocation (RMI). By using these objects, ESs communicate with the core storage system, forwarding new events from vehicles and road hardware. The Internet Traffic Operation Server (ITOS) provides a Web access with a complete view of road events. To this end, ITOS analyzes the roadside information, accessible via the core storage manager. This Web application offers a differentiated access to users and operators, by means of an authentication stage. Operators, unlike normal system clients or users, have an administration account with management capabilities. Furthermore, any user of the Web application is able to check the state of the roads, at home or even using the on-board computer, via the Internet connection.From this architecture explanation it can be seen that information from subscribed services is sent or received by means of events. These come directly from other vehicles or from the infrastructure, via ES entities. Events from the roadside have a local scope, because they comprise context-aware information exchanged in a V2V pattern. Due to hand-offs between coverage areas, it is necessary for vehicles to receive important events of the new area they enter, which were previously collected from the roadside. ITOS carries out this task through a TCP/IP-based protocol, as Figure1 shows.


## 5. Management of Contextual Information

The efficient management of contextual information is a key feature of the architecture presented in this proposal. As explained in this section, this information is represented here by the points of interest (POI) of the road and drivers' profiles. The platform uses a rule-based reasoning system to match the preferences contained in the drivers' profiles with the characteristics of nearby POI. As a result, relevant information for the drivers is inferred when they are driving along services areas. This functionality is offered as a service implemented in the platform, which is accessible by users. The adaptation of the contextual information to each particular driver is the ultimate goal of the context manager subsystem introduced in this section.


### 5.1. Ontology-Based Modeling and Inference

The ability of beingcontext-aware is receiving a considerable attention when applying it to mobile devices, as these devices are particularly affected by environmental changes. A general motivation is that context-awareness can serve to compensate for the abstraction that is required to make systems react and adapt “sensibly” to changing environments and situations. According to [19], “context is any information that can be used to characterize the situation of an entity. An entity is a person, a place, or object that is considered relevant to the interaction between a user and an application.” Therefore, a context-aware system needs to maintain a contextual interpretation of a situation. This implies the use of some type of knowledge representation directed to introduce context information in the system and the capability to reason about this knowledge.One appealing alternative to represent context information is offered by means of Semantic Web ontologies [20]. An ontology, related to the computer science field, is a formal representation of a set of concepts within a domain and the relationships between those concepts. From this conceptualization, it is possible to define a specific situation in the domain by instantiating the concepts and their relations. A Semantic Web-based ontology uses the same conceptualization idea, and moreover it is explicitly augmented with semantic axioms (e.g., subsumption of concepts, disjointness, etc.). Several advantages are acquired by using domain representations based on Semantic Web ontologies. Firstly, the information represented by this kind of ontologies can be easily and broadly exchanged among heterogeneous applications which share the same conceptualization. Another fundamental capability provided by adding semantics to a domain representation is the execution of inference processes over such a domain. One of the results of these processes is the extraction of new knowledge that was implicit in the domain. This kind of inference process is achieved by triggering some predefined set of rules about concept hierarchy, types of relationships, instances of concepts, and so forth. stated in the ontology. Taking this idea further, we can define our own rule set to infer new knowledge according to the contextual information modeled in the domain (i.e., POI and drivers' profiles). Thus, the overlay network system will react by offering relevant information to the drivers regarding the context in the ongoing situation.There are several languages for describing Semantic Web ontologies, such as RDF (Resource Description Framework) [21] and OWL (Web Ontology Language) [22]. Furthermore, the latter has been adopted as standard by the W3C (http://www.w3.org/2004/OWL/). In particular, the ontologies developed in the overlay communication platform are written in OWL-DL, a broadly used OWL version which takes Description Logic (DL) [23] as its formal underlying language. In this paper ontologies are presented at a high level of abstraction, since such a level is enough to show their aim and functionality in the platform. The reader is referred to the references above for OWL's syntax and further details.Once the contextual information has accordingly been modeled by means of OWL-DL ontologies, this model can now be used to produce rules, calledcontext rules henceforth. Context rules provide a means to infer how the overlay network system should react (e.g., to send notifications) according to the context in the road side (e.g., nearby POI or situation of interest such as traffic jams) and drivers' profiles. Namely, these rules allow expressing some specific situations based on the vehicle context and the desirable reaction that should be performed in the system when such a situation occurs. In this sense, the rules introduce knowledge to be interpreted by the system according to the current context of a situation. The deductive process necessary to execute context rules on ontologies is achieved by means of the Jena framework [24]. Jena provides a set of methods for loading and managing OWL ontologies, together with a rule-based reasoning engine. Now, let us see each of these components in detail.


### 5.2. Determining the Vehicle Context

The first question posed when defining the vehicle context is which elements comprise this kind of context.Location is the most widespread context source [25]. As a result, the location-based services (LBSs) are considered as a particular case of general context-aware applications. Proliferation of navigation devices has attracted the LBS concept to different areas such as creation of new services in mobile phones or intelligent transport systems. Apart from location, there exist other context sources which are also important. All these sources are identified by the “5Ws” [26]: who, the identification of a user of the system and the role that user plays within the system in relation to other users; what, the recognition of activities and tasks users are performing; where, the tracking of the location where a user or object is geographically located at each moment; when, defining the instant of access to the system; and why, the capacity to infer and understand the intentions and goals behind activities, which is one of the hardest challenges in this field, but at the same time a fundamental one for enabling the system to anticipate users' needs.In order to consider all these factors, not only should location technologies (e.g., presence sensors) be employed, but also other fields such as artificial vision or environment sensing (e.g., temperature, humidity, and pressure) could be present in the architecture. As a result, in this paper we gather the elements needed in the platform to determine the vehicle context by means of three main concepts: vehicle location, service, and identity. These concepts are built upon the vehicles and drivers information retrieved by the overlay network.


#### 5.2.1. Vehicle Location

The vehicle's geographical position is a key feature with respect to the propagation and reception of information in a specific area of interest (where). The navigation system included in the vehicle enables its localization in the road network. On the other hand, the communication architecture manages the notifications received and transmitted from and to the vehicles both at local and global levels. Indeed, this centralized management allows the architecture to notify previous events, mainly related to traffic incidents, which are still valid in the current context (when).


#### 5.2.2. Service

Each service represents the type of information which users or applications are interested in. Since each communication service is goal-oriented, it is possible to determinate what activity is the user performing due to his interest in a particular type of information (what). In the proposed architecture, both users and applications can subscribe to specific communication services, thus avoiding the rest of notifications related to other services which are not relevant for them. A diversified offer of services may help to delimit the activity performed by the driver. For instance, subscribing a tour-guided service or asking information for public parking places gives meaningful information about the type of ongoing activity.


#### 5.2.3. Identity

The proposed context management system enables the customization of the information provided by the platform once the driver is identified (who). This process is composed of two steps. The first one is based on the identification of vehicles, which allows the overlay network to identify the driver and retrieve his profile. The second step uses these drivers' profiles to execute the service according to the preferences included in them. Both drivers' profiles and identification of vehicles are supported by ontology models and RFID (Radio Frequency Identification), respectively.


### 5.3. Ontology Models and Information Management

The representation of contextual information in this proposal has been modeled by means of two OWL-DL ontologies: TheProfile ontology, which defines a schema with the different driver's preferences about restaurants, hotels, museums, and so on (e.g., price and quality rates); and the Environment ontology, which represents the points of interest which can be found in each service area: restaurants, hotels, petrol stations, or touristic places such as churches, shopping centers, museums, and so on. The schema of this latter ontology is depicted in Figure 2. The use of these ontologies suits smoothly with the information management requirements in the ITS platform depicted in Figure 1. This requirement is based on the distributed composition of such an architecture. Consequently, the ontologies are spread among its different components. Notice that it is important to distinguish between the schema and the instances of an ontology. While there is only one schema that represents the domain being modeled, there could be several instances of that schema for the specific information captured. For example, there is (at least) one instance of the Profile ontology schema for each driver. On the other hand, there exists an instance of the Environment ontology schema for each correspondent service area which represents the available POI in such an area.Figure 2
Hierarchical representation of Environment ontology schema.In order to process the local notifications in the service areas, the ontologies have been allocated in their appropriate component of the architecture. The instances of the Profile ontology are maintained in the Profile Manager, as part of the Distributed Core Storage element. The ITOS Web front-end gives access to the drivers' profiles stored here. Contrarily, the instances of the Environment ontology are distributed among the ESs. This organization is justified because Environment Servers are responsible for updating the state of the road and POIs in their areas, whereas the drivers' profiles should be in a global and centralized point, so as to be rapidly transferred to the correspondent ES when a driver is detected in its area. The instances of the Environment ontology can be locally managed in each ES or remotely, via the ITOS Web front-end.


### 5.4. Adapting Contextual Information

When a vehicle is detected in a delimited service area, the ES associated to that area obtains the driver's profile from the Profile Manager and then it infers new information of interest for the driver (if any). Figure3 shows a sequence diagram with the elements involved during the management of contextual information. Observe that the method by which the ES detects the location of the vehicle is independent from the inference process and the knowledge model. In our proposed platform, an RFID system is used to detect the presence of a vehicle. After detecting it, the RFID system sends a Reader_Notification message to the ES. This message includes the vehicle's RFID tag identifier, which determines the driver unambiguously. This notification protocol has been deployed over a TCP/IP connection. Then, the ES requests the driver's profile to the Profile Manager by invoking the profileRequest remote method with the RFID tag identifier as parameter. Once the driver's profile is retrieved, the ES processes the local information about the area, together with this profile, to infer the interesting notifications in that area. When the inference process is executed, the ES sends a Specific_Environment_Event message to the correspondent vehicle by means of the P2P JXTA network. This message contains the resulting matches together with a matching ratio. Finally, the on-board unit in the vehicle is in charge of displaying this information for the driver in an appropriate manner.Figure 3
Sequence diagram for adapting contextual information.The inference process in the ES follows the next steps. First, the driver's profile is combined with the instance of the Environment ontology maintained in this ES. Then, the context rules defined in the system are executed over the combination of this contextual information. Context rules are in the form of(1)X1⋀X2⋀⋯⋀Xn→Y1⋀Y2⋀⋯⋀Ym,
that is, an “if-then” implication between a conjunction of antecedents Xi and consequents Yj (the symbol ⋀ represents the logical conjunction “and”). These rules contain concepts, relationships, and instances described in OWL-DL ontologies. More specifically, each Xi/Yj is a triple (s,p,o), where s (subject) is an instance of a concept, p (predicate) is a relationship among concepts or a data property of a concept, and o (object) is a concept, an instance, or a data value. Note that s, p, and o could be variables to be instantiated when evaluating the rules. Each triple represents an assertion in the domain model, that is, a fact about the current context. The semantic of these rules states that whenever all the triples specified in the antecedent are true in a domain, the triples in the consequent must also be true in such a domain.Finally, context rules are evaluated by a deductive inference process, which is performed by the Jena rule-based reasoning engine integrated into each ES. For each context rule available, the reasoning engine checks if its antecedents are satisfied in the contextual information maintained in the ES. As seen before, this information is obtained after combining the correspondent driver's profile and POI data, represented as instances of the Profile and Environment ontologies, respectively. The inferred information in the consequents of each triggered rule is then added to the driver's profile and notified to the ES. Consequently, the ES can now send such inferred information to the driver's vehicle, as explained above.The next rulemenuPrice is shown as an example of context rule. Variables are represented by a string starting with the symbol “?”. The rest of elements are concepts or relationships defined in the Profile and Environment ontology, denoted by the prefixes prf and srv, respectively. Particularly, this rule searches for a driver's profile (1) which contains preferences about restaurants (2); according to a preferred maximum and minimum menu price (3),(4) the driver is willing to pay. Then, if any restaurant in the Environment ontology (5) has a menu (6) whose price is less or equal than the preferred maximum price ((7), “le” is the comparison operator less or equal) and greater or equal than the preferred minimum price ((8), “ge” is the comparison operator greater or equal), the evaluated restaurant is added to the list of driver's profile matches (9), specifying the menu price condition as satisfied (10):[menuPrice:(1)
(?profile rdf:type prf:Profile)(2)
(?profile prf:restaurantProfile ?rp)(3)
(?rp prf:maxMenuPrice ?maxmp)(4)
(?rp prf:minMenuPrice ?minmp)(5)
(?res rdf:type srv:Restaurant)(6)
(?res srv:menuPrice ?mp)(7)
le (?mp,?maxmp)(8)
ge (?mp,?minmp)->(9)
(?profile prf:matches ?res)(10)
(?res srv:matcheswith “menuPrice”)]Observe that some functions such as mathematical operations (e.g., comparisons of greater and lesser) could also be part of the antecedents and consequents. Context rules like the previous one are written by system administrators according to a set of templates which are used to collect the drivers' requirements. This process is assisted by a Web interface at ITOS. Administrators are assisted in writing the rules by a tool called ORE (Ontology Rule Editor) (http://sourceforge.net/projects/ore) [27] which has been developed within our research group. Since these context rules are defined by using elements of the Profile and Environment ontologies, they can be combined with any specific instances of both ontologies. As a result, the same rules can be executed in any ES, but the results could be different depending on the contextual information maintained in each ES.


## 5.1. Ontology-Based Modeling and Inference

The ability of beingcontext-aware is receiving a considerable attention when applying it to mobile devices, as these devices are particularly affected by environmental changes. A general motivation is that context-awareness can serve to compensate for the abstraction that is required to make systems react and adapt “sensibly” to changing environments and situations. According to [19], “context is any information that can be used to characterize the situation of an entity. An entity is a person, a place, or object that is considered relevant to the interaction between a user and an application.” Therefore, a context-aware system needs to maintain a contextual interpretation of a situation. This implies the use of some type of knowledge representation directed to introduce context information in the system and the capability to reason about this knowledge.One appealing alternative to represent context information is offered by means of Semantic Web ontologies [20]. An ontology, related to the computer science field, is a formal representation of a set of concepts within a domain and the relationships between those concepts. From this conceptualization, it is possible to define a specific situation in the domain by instantiating the concepts and their relations. A Semantic Web-based ontology uses the same conceptualization idea, and moreover it is explicitly augmented with semantic axioms (e.g., subsumption of concepts, disjointness, etc.). Several advantages are acquired by using domain representations based on Semantic Web ontologies. Firstly, the information represented by this kind of ontologies can be easily and broadly exchanged among heterogeneous applications which share the same conceptualization. Another fundamental capability provided by adding semantics to a domain representation is the execution of inference processes over such a domain. One of the results of these processes is the extraction of new knowledge that was implicit in the domain. This kind of inference process is achieved by triggering some predefined set of rules about concept hierarchy, types of relationships, instances of concepts, and so forth. stated in the ontology. Taking this idea further, we can define our own rule set to infer new knowledge according to the contextual information modeled in the domain (i.e., POI and drivers' profiles). Thus, the overlay network system will react by offering relevant information to the drivers regarding the context in the ongoing situation.There are several languages for describing Semantic Web ontologies, such as RDF (Resource Description Framework) [21] and OWL (Web Ontology Language) [22]. Furthermore, the latter has been adopted as standard by the W3C (http://www.w3.org/2004/OWL/). In particular, the ontologies developed in the overlay communication platform are written in OWL-DL, a broadly used OWL version which takes Description Logic (DL) [23] as its formal underlying language. In this paper ontologies are presented at a high level of abstraction, since such a level is enough to show their aim and functionality in the platform. The reader is referred to the references above for OWL's syntax and further details.Once the contextual information has accordingly been modeled by means of OWL-DL ontologies, this model can now be used to produce rules, calledcontext rules henceforth. Context rules provide a means to infer how the overlay network system should react (e.g., to send notifications) according to the context in the road side (e.g., nearby POI or situation of interest such as traffic jams) and drivers' profiles. Namely, these rules allow expressing some specific situations based on the vehicle context and the desirable reaction that should be performed in the system when such a situation occurs. In this sense, the rules introduce knowledge to be interpreted by the system according to the current context of a situation. The deductive process necessary to execute context rules on ontologies is achieved by means of the Jena framework [24]. Jena provides a set of methods for loading and managing OWL ontologies, together with a rule-based reasoning engine. Now, let us see each of these components in detail.


## 5.2. Determining the Vehicle Context

The first question posed when defining the vehicle context is which elements comprise this kind of context.Location is the most widespread context source [25]. As a result, the location-based services (LBSs) are considered as a particular case of general context-aware applications. Proliferation of navigation devices has attracted the LBS concept to different areas such as creation of new services in mobile phones or intelligent transport systems. Apart from location, there exist other context sources which are also important. All these sources are identified by the “5Ws” [26]: who, the identification of a user of the system and the role that user plays within the system in relation to other users; what, the recognition of activities and tasks users are performing; where, the tracking of the location where a user or object is geographically located at each moment; when, defining the instant of access to the system; and why, the capacity to infer and understand the intentions and goals behind activities, which is one of the hardest challenges in this field, but at the same time a fundamental one for enabling the system to anticipate users' needs.In order to consider all these factors, not only should location technologies (e.g., presence sensors) be employed, but also other fields such as artificial vision or environment sensing (e.g., temperature, humidity, and pressure) could be present in the architecture. As a result, in this paper we gather the elements needed in the platform to determine the vehicle context by means of three main concepts: vehicle location, service, and identity. These concepts are built upon the vehicles and drivers information retrieved by the overlay network.


### 5.2.1. Vehicle Location

The vehicle's geographical position is a key feature with respect to the propagation and reception of information in a specific area of interest (where). The navigation system included in the vehicle enables its localization in the road network. On the other hand, the communication architecture manages the notifications received and transmitted from and to the vehicles both at local and global levels. Indeed, this centralized management allows the architecture to notify previous events, mainly related to traffic incidents, which are still valid in the current context (when).


### 5.2.2. Service

Each service represents the type of information which users or applications are interested in. Since each communication service is goal-oriented, it is possible to determinate what activity is the user performing due to his interest in a particular type of information (what). In the proposed architecture, both users and applications can subscribe to specific communication services, thus avoiding the rest of notifications related to other services which are not relevant for them. A diversified offer of services may help to delimit the activity performed by the driver. For instance, subscribing a tour-guided service or asking information for public parking places gives meaningful information about the type of ongoing activity.


### 5.2.3. Identity

The proposed context management system enables the customization of the information provided by the platform once the driver is identified (who). This process is composed of two steps. The first one is based on the identification of vehicles, which allows the overlay network to identify the driver and retrieve his profile. The second step uses these drivers' profiles to execute the service according to the preferences included in them. Both drivers' profiles and identification of vehicles are supported by ontology models and RFID (Radio Frequency Identification), respectively.


## 5.2.1. Vehicle Location

The vehicle's geographical position is a key feature with respect to the propagation and reception of information in a specific area of interest (where). The navigation system included in the vehicle enables its localization in the road network. On the other hand, the communication architecture manages the notifications received and transmitted from and to the vehicles both at local and global levels. Indeed, this centralized management allows the architecture to notify previous events, mainly related to traffic incidents, which are still valid in the current context (when).


## 5.2.2. Service

Each service represents the type of information which users or applications are interested in. Since each communication service is goal-oriented, it is possible to determinate what activity is the user performing due to his interest in a particular type of information (what). In the proposed architecture, both users and applications can subscribe to specific communication services, thus avoiding the rest of notifications related to other services which are not relevant for them. A diversified offer of services may help to delimit the activity performed by the driver. For instance, subscribing a tour-guided service or asking information for public parking places gives meaningful information about the type of ongoing activity.


## 5.2.3. Identity

The proposed context management system enables the customization of the information provided by the platform once the driver is identified (who). This process is composed of two steps. The first one is based on the identification of vehicles, which allows the overlay network to identify the driver and retrieve his profile. The second step uses these drivers' profiles to execute the service according to the preferences included in them. Both drivers' profiles and identification of vehicles are supported by ontology models and RFID (Radio Frequency Identification), respectively.


## 5.3. Ontology Models and Information Management

The representation of contextual information in this proposal has been modeled by means of two OWL-DL ontologies: TheProfile ontology, which defines a schema with the different driver's preferences about restaurants, hotels, museums, and so on (e.g., price and quality rates); and the Environment ontology, which represents the points of interest which can be found in each service area: restaurants, hotels, petrol stations, or touristic places such as churches, shopping centers, museums, and so on. The schema of this latter ontology is depicted in Figure 2. The use of these ontologies suits smoothly with the information management requirements in the ITS platform depicted in Figure 1. This requirement is based on the distributed composition of such an architecture. Consequently, the ontologies are spread among its different components. Notice that it is important to distinguish between the schema and the instances of an ontology. While there is only one schema that represents the domain being modeled, there could be several instances of that schema for the specific information captured. For example, there is (at least) one instance of the Profile ontology schema for each driver. On the other hand, there exists an instance of the Environment ontology schema for each correspondent service area which represents the available POI in such an area.Figure 2
Hierarchical representation of Environment ontology schema.In order to process the local notifications in the service areas, the ontologies have been allocated in their appropriate component of the architecture. The instances of the Profile ontology are maintained in the Profile Manager, as part of the Distributed Core Storage element. The ITOS Web front-end gives access to the drivers' profiles stored here. Contrarily, the instances of the Environment ontology are distributed among the ESs. This organization is justified because Environment Servers are responsible for updating the state of the road and POIs in their areas, whereas the drivers' profiles should be in a global and centralized point, so as to be rapidly transferred to the correspondent ES when a driver is detected in its area. The instances of the Environment ontology can be locally managed in each ES or remotely, via the ITOS Web front-end.


## 5.4. Adapting Contextual Information

When a vehicle is detected in a delimited service area, the ES associated to that area obtains the driver's profile from the Profile Manager and then it infers new information of interest for the driver (if any). Figure3 shows a sequence diagram with the elements involved during the management of contextual information. Observe that the method by which the ES detects the location of the vehicle is independent from the inference process and the knowledge model. In our proposed platform, an RFID system is used to detect the presence of a vehicle. After detecting it, the RFID system sends a Reader_Notification message to the ES. This message includes the vehicle's RFID tag identifier, which determines the driver unambiguously. This notification protocol has been deployed over a TCP/IP connection. Then, the ES requests the driver's profile to the Profile Manager by invoking the profileRequest remote method with the RFID tag identifier as parameter. Once the driver's profile is retrieved, the ES processes the local information about the area, together with this profile, to infer the interesting notifications in that area. When the inference process is executed, the ES sends a Specific_Environment_Event message to the correspondent vehicle by means of the P2P JXTA network. This message contains the resulting matches together with a matching ratio. Finally, the on-board unit in the vehicle is in charge of displaying this information for the driver in an appropriate manner.Figure 3
Sequence diagram for adapting contextual information.The inference process in the ES follows the next steps. First, the driver's profile is combined with the instance of the Environment ontology maintained in this ES. Then, the context rules defined in the system are executed over the combination of this contextual information. Context rules are in the form of(1)X1⋀X2⋀⋯⋀Xn→Y1⋀Y2⋀⋯⋀Ym,
that is, an “if-then” implication between a conjunction of antecedents Xi and consequents Yj (the symbol ⋀ represents the logical conjunction “and”). These rules contain concepts, relationships, and instances described in OWL-DL ontologies. More specifically, each Xi/Yj is a triple (s,p,o), where s (subject) is an instance of a concept, p (predicate) is a relationship among concepts or a data property of a concept, and o (object) is a concept, an instance, or a data value. Note that s, p, and o could be variables to be instantiated when evaluating the rules. Each triple represents an assertion in the domain model, that is, a fact about the current context. The semantic of these rules states that whenever all the triples specified in the antecedent are true in a domain, the triples in the consequent must also be true in such a domain.Finally, context rules are evaluated by a deductive inference process, which is performed by the Jena rule-based reasoning engine integrated into each ES. For each context rule available, the reasoning engine checks if its antecedents are satisfied in the contextual information maintained in the ES. As seen before, this information is obtained after combining the correspondent driver's profile and POI data, represented as instances of the Profile and Environment ontologies, respectively. The inferred information in the consequents of each triggered rule is then added to the driver's profile and notified to the ES. Consequently, the ES can now send such inferred information to the driver's vehicle, as explained above.The next rulemenuPrice is shown as an example of context rule. Variables are represented by a string starting with the symbol “?”. The rest of elements are concepts or relationships defined in the Profile and Environment ontology, denoted by the prefixes prf and srv, respectively. Particularly, this rule searches for a driver's profile (1) which contains preferences about restaurants (2); according to a preferred maximum and minimum menu price (3),(4) the driver is willing to pay. Then, if any restaurant in the Environment ontology (5) has a menu (6) whose price is less or equal than the preferred maximum price ((7), “le” is the comparison operator less or equal) and greater or equal than the preferred minimum price ((8), “ge” is the comparison operator greater or equal), the evaluated restaurant is added to the list of driver's profile matches (9), specifying the menu price condition as satisfied (10):[menuPrice:(1)
(?profile rdf:type prf:Profile)(2)
(?profile prf:restaurantProfile ?rp)(3)
(?rp prf:maxMenuPrice ?maxmp)(4)
(?rp prf:minMenuPrice ?minmp)(5)
(?res rdf:type srv:Restaurant)(6)
(?res srv:menuPrice ?mp)(7)
le (?mp,?maxmp)(8)
ge (?mp,?minmp)->(9)
(?profile prf:matches ?res)(10)
(?res srv:matcheswith “menuPrice”)]Observe that some functions such as mathematical operations (e.g., comparisons of greater and lesser) could also be part of the antecedents and consequents. Context rules like the previous one are written by system administrators according to a set of templates which are used to collect the drivers' requirements. This process is assisted by a Web interface at ITOS. Administrators are assisted in writing the rules by a tool called ORE (Ontology Rule Editor) (http://sourceforge.net/projects/ore) [27] which has been developed within our research group. Since these context rules are defined by using elements of the Profile and Environment ontologies, they can be combined with any specific instances of both ontologies. As a result, the same rules can be executed in any ES, but the results could be different depending on the contextual information maintained in each ES.


## 6. Prototype Set-Up

A prototype vehicle [28] has been set up with the necessary hardware and software to deploy the on-board part of the architecture previously presented. An FV-21 positioning sensor and a UMTS Huawei E220 modem, which support HSDPA, have been used to provide positioning (through the on-board navigation system [29]) and communication capabilities. The Environment Server entity has been implemented and installed on several Linux-based PCs, using a Java environment and the Jena framework. To test the connection between an ES and the rest of road side hardware, an RFID reader has been set up to detect the presence of vehicles through a tag affixed to the windscreen. The same RFID approach or any other positioning technology (such as cell determination in UMTS) could be added to the platform, in order to improve the reliability of the system when vehicles are identified in service areas.The photographs included in Figure4 show the previous set-up. The RFID reader (a WaveTrend AA-R500-SP) has been installed at the test place using an ad hoc gantry. A laptop is connected via serial port to the reader, in order to send presence notifications to the corresponding ES. This communication has not been secured for the moment, but it is envisaged to secure these messages through SSL, as in the rest of TCP connections. From a wide set of tests with the RFID gantry, it has been checked that good identification rates are obtained at speeds under 50 km/h; hence, it is specially appropriate for urban environments or service stations, for instance. The Group Server and the Internet Traffic Operation Server have been developed in Java and then installed over a high-performance server, in order to cover high rates of queries. The distributed core storage manager is composed of a set of RMI entities, which perform information management tasks (Profile Manager, User Manager and Road Event Manager), and a remote MySQL database which physically stores all data. The RMI entities work as independent applications, and each one publishes a remote object which is used by the ITOS and ES. In our prototype, the RMI applications and the MySQL server run on the high-end computer, but they could have been installed on different hosts.Hardware set-up of the RFID identification prototype.
(a)
RFID reader.(b)
Computer connected with the reader.(c)
Vehicle used in the operation tests.(d)
RFID tag.A new module has been included in the software platform of the on-board computer [30], which is based on Java and OSGi (Open Services Gateway Initiative), to offer JXTA communications through multicast pipes. This module makes P2P programming tasks easier to the developer. A service has also been implemented to access the networking architecture through several reference services. This is the Message Console, which appears in Figure 5. The user connects to the services he is interested in by pressing the available buttons on the right part of the window. When the activated services appear in the current coverage zone, their corresponding images appear below, and it is possible to receive events from outside or send a new one. The central part of the window shows all the received messages about all active services (road incidences, weather, tourist information, etc.). In this example, the vehicle has received information about hotels and cinemas. The service which provides such information is called “On Road Information” and uses the RFID system to locate the vehicle at a specific place. When the ES receives the presence notification, it asks the core infrastructure for the user's profile. Then, the ES infers interesting information for the driver, via its local database about the environment. Finally, the ES sends this information to the vehicle, including the matching rate for every point of interest notified. In the example, the hotels which best suit the user's preferences are “AC Elche,” “NH Amistad,” and “NH Rincon de Pepe,” with a matching rate of 43%. This suitability rate is calculated considering the number of matching features between the user's profile and the POI element.Figure 5
On-board software with traffic and POI notification services.The navigation capabilities of the on-board software are also showed in Figure5. This feature is currently implemented to support both Google Maps (in the image) and digital cartography. The software draws both previous road problems, received during the hand-off, and the new ones, by means of icons over the road. The polygon which covers the current coverage area is also depicted using a light red line. When the vehicle is close to a road event (initially sent by a vehicle, a roadside sensor or manually fixed by an operator), the application shows a warning about it and the remaining distance to reach the incidence. Further details about the incidence are also given through a spoken alert, by means of a speech synthesizer. In the example, a warning about the proximity of a breakdown on the road has been raised. This event is represented as a yellow mark on the map. As can be seen, the user is always informed of a notification by means of the warning icon, the spoken alert, and the navigation map. The central text panel also notifies traffic incidences from other vehicles (V2V) or roadside sensors (I2V). Messages received from the information service which provides contextual notifications about near POIs are also showed in this part of the interface. All these messages are also read by the integrated speech synthesizer for safety reasons.In Figure6 there is a screenshot of the Web application located at ITOS, implemented using JSP. In the map view provided, a road operator has logged in and it is currently reading information about a meteorology event reported by a vehicle in the surroundings of Madrid. Road incidences are depicted over a Google Maps interface using different marks for each incidence type. All road event types can be seen on the left part of the window. Further information about incidences can be accessed by clicking on the icon. A normal user or driver is only allowed to see information about the road network, but the operator can also insert, delete, or modify events and manage the users registered in the system. Each user can, nevertheless, change his own profile via this application. Among other views, there is a specific one dedicated to edit users' profile by means of several templates, enabling them to change their preferences. In this manner they can vary the information received from the infrastructure by means of the adaptation scheme previously explained. To date, several features can be selected about several kinds of POI, such as cinemas, restaurants, petrol stations, and service areas.Figure 6
Road incidences monitoring at the ITOS Web application.


## 7. Performance of the Information Adaptation Subsystem

One key aspect when evaluating the information adaption subsystem is the amount of time employed during the inference and delivery of interesting notifications to the driver. In vehicular environments, the notifications must be timely sent to the vehicle before it leaves the coverage area related to this information. Regarding the performance of the overlay network, an exhaustive analysis under real conditions is given in [31]. Here, it has been proven the feasibility of the vehicular network to send messages following V2V, V2I, and I2V communication patterns. According to collected results, 95% of delay values are under 500 miliseconds, although the V2V case presents a greater jitter, because both the uplink and the downlink channels of UMTS are used. For the evaluation of the information adaptation subsystem, only the I2V link is used, but the performance study is directed to the time needed for interring contextual notifications to users.In order to evaluate the performance of the information adaptation subsystem, we have developed a model that contains enough information to deal with real situations and different users' profiles. This model is composed of eleven concepts in the Profile ontology, which represent the different users' preferences about POIs (type of fuel, food likes, preferred cinema genre, etc.). Moreover, eighteen concepts in the Environment ontology represent the available POIs in this model. These can be seen in Figure2. An Environment Server has been set up to simulate the area where the car is currently driving along. This server contains one hundred and ten instances of POI concepts, such as instances of restaurants, cinemas, and hotels. Moreover, thirty-two context rules have been defined to match the drivers' profiles with these points of interest. Four different instances of user profiles have been proposed to test the system responses. Each profile is centered on different types of services. Thus, Pr is more keen on restaurants, Pc on cinemas, Ph on hotels, and Pm is a combination of these three. The performance test has been divided into three steps.(1)The initialization of the knowledge base. In this step, the Environment and Profile ontologies are retrieved in the ES from the permanent storage device, together with the POI instances. Moreover, the specific drivers' profiles (instances of the Profile ontology) for the scenario are also retrieved, together with the context rules associated to these profiles. Ontologies, instances, and context rules are locally stored in the ES.(2)Inference process. The context rules are applied over each of the drivers' profiles in order to match them with the relevant POIs in the Environment ontology.(3)Collection of matches. In this step, the POIs matched with each driver's profile are retrieved and notified to the correspondent driver, along with the matching ratio according to each profile.The Environment Server employed for this test is an Intel Pentium D 3 Ghz with 1 GB of RAM running under Linux, with the same Java and Jena set-up considered in the final platform. The previous scenario has been simulated with this equipment to easy the performance study under consideration, but the whole platform has been checked in real conditions, as can be seen in [31].Table4 shows the obtained results for the four profile tests performed. The most expensive operation is the initialization of the knowledge base, normally two or three seconds. However, since this process is performed once during the ES setting-up, it does not affect to the normal operation of the system. The table reflects that the initialization time depends on the knowledge base size. As a result, since Pm contains the profiles used in the three previous tests, the initialization carried out with this profile takes longer. More relevant are the results of the inference process and the collecting matches tasks, both critical processes when a vehicle is driving through an ES area. The inference process is more time-consuming than the collection of matches, due to the triggering of rules on the whole knowledge base. Contrarily, the collection of matches is only executed on the POIs retrieved by the inference process. In this task, the fetched POIs are decreasingly ordered according to the matching ratio. Finally, they are parsed into a text string and sent to the vehicle. The results in Table 4 show that the inference process takes longer as the profile is more complex, but it still stays within acceptable levels. Furthermore, the time consumed in the collecting matches task depends on the number of matches found, always being lower than the time in inference process.Table 4
Evaluation results of the system performance.
ProfileKnowledge BaseInference ProcessCollectInitialization (ms)(ms)Matches (ms)Pr248425062Pc262528163Ph289031347Pm3410381105Regarding the specific values in Table4, the results for the profiles Pr, Pc, and Ph are similar, although the time for each task slightly increases from restaurant profile Pr to cinema profile Pc and from Pc to hotel profile Ph. Taking into account that the ontology model and the number of instances (i.e., hotels, restaurants, cinemas, etc.) are equal in the three cases, the differences stem from the driver's preferences. Examining the correspondent preferences with respect to the available POIs, it is detected that seven restaurants are matched with the available POIs, while the number of matching cinemas and hotels is eight and ten, respectively. Moreover, when matching the POIs in the cinema profile, it is necessary to check all the available movies in each one, which are represented by a relationship to the concept Film in the model (see Figure 2). Likewise, the higher number of matches of hospitals in profile Ph increases the time of inferencing and collecting matches. In relation to profile Pm, it contains the three previous profiles. As a result, the times for initialization, inference, and collection of matches are higher than in the rest of profiles. This increase is particularly higher in the last task, because the number of matches is considerably higher than in the previous cases. However, the resulting times for the two critical tasks in the information adaption subsystem, namely, inference and collection of matches, are below 400 miliseconds in all cases, thus being acceptable for any vehicle in an ES coverage area.


## 8. Conclusions and Future Work

The work presented in this paper covers an integral design of a telematic infrastructure for ITS services deployment oriented to the provision of contextual information. A communication architecture has been designed, developed, and extensively evaluated in a previous work [31]. The additional support of the infrastructure side is a key factor to offer global processing and contextual integration. The overlay network designed is based on the concept of P2P communication groups, which are used to bound the propagation of messages generated by vehicles and the ones received from the infrastructure in each service area. Vehicles perform a handover process through these areas in order to maintain a communication channel with a concrete service. This idea has been exploited through a network platform which comprises both the on-board unit and several entities located at the road side and the core infrastructure. The UMTS cellular network is used as communication technology, since continuous improvements in operator's infrastructures encourage its use in many ITS services.Vehicle integration in the traffic context is a key work in the paper. In addition to the event-based communication channel, which enables vehicles and road-side units to exchange local information, a complementary support at the infrastructure side offers global processing capabilities and information adapted according to the user's preferences. A Web-based system integrates digital cartography functionalities to allow users and road operators to monitor the road network state. Moreover, an ontology-based reasoning subsystem adapts contextual information according to the user's profiles. This part of the work has been extended with an RFID-based identification platform, in order to detect the vehicle presence at specific locations and send adapted POI notifications. One of the two new software modules added in the on-board unit presents a user interface able to warn the user about traffic incidences and show POI notifications received from the infrastructure.Considering the whole prototype of the platform presented here, it is appreciable the work needed to integrate the multiple technologies used in the architecture. In the operation tests carried out in final stages of the project, it has been proven that all functionalities identified in the paper work correctly, although further work is needed to accomplish a final solution ready for the massive usage in such a dynamic environment as the transportation one. These technical improvements are focused on providing a secure message passing and reliable communications, upgrading the P2P network to be proof against UMTS discontinuities.As can be seen, the telematic platform is able to support a wide range of ITS services related to information provision. In fact, several reference services have been included in the implementation. In next steps, this platform will be updated according to some ongoing and future research lines. New advances in cellular communications have recently appeared (such as HSUPA, or High-Speed Uplink Packet Access), and some others are going to do so in next months. Hence, new experimental tests and platform upgrades will be done regarding the communication architecture. The MBMS technology is expected to present a great technological advance for traffic information provision. The advantages of this technology could be combined with a group-based P2P scheme as the one presented. WiMAX evaluation is an ongoing work at the University of Murcia, and since the proposed overlay network is independent on the communication technology, the integration of both concepts is an interesting future line. At the service level, current works are directed to take advantage of digital cartography to provide extended services at both the vehicle and infrastructure sides.



---

*Source: 216582-2010-02-23.xml*