Beaconing support in Publish-Subscribe Middleware for Vehicular Applications Vittoria Gianuzzi
Alessio Merlo
DISI – Università di Genova Via Dodecaneso, 35 16136, Genova, Italy Tel. 0039 010 353 6602
DIST – Università di Genova Via all'Opera Pia, 13 16145, Genova, Italy Tel. 0039 010 353 2344
[email protected]
[email protected] ABSTRACT Vehicular Ad hoc Network (VANET) is a wireless network formed on the fly among vehicles connected by wireless links. A VANET application can learn about the context by acquiring and parsing beacons periodically broadcasted by other vehicles. In this paper we investigate the requirements of the applications that use vehicle beaconing to increase safety of road transportations and to provide drivers with sensitive information about traffic condition. On this topic, an open issue is related to the analysis and management of the beacon stream by means of a suitable middleware. To this aim, we discuss the design of a Publish-Subscribe based middleware for VANET applications, namely ACME, tailored to accomplish suitable queries over the beacons in a flexible and adaptive way, satisfying the applications requirements. Finally, a prototype implementation of ACME is presented1.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques Modules and interfaces; C.2.4 [Computer-Communication etworks]: Distributed Systems - Distributed applications; C.2.1 [Computer-Communication etworks]: Network Architecture and Design - Wireless communication
General Terms Design, Experimentation
Keywords Vehicular networks, Context-awareness, Middleware, PublishSubscribe systems.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. M-MPAC 2010, November 29th, 2010, Bangalore, India. Copyright 2010 ACM 978-1-4503-0451-1/10/11...$10.00
1.
I TRODUCTIO
In distributed environments, new applications are emerging thanks to the deployment of pervasive communications spanning from short-ranged wireless sensors networks to globe-wide intra/inter-nets. This new class of applications takes to new research challenges, that cannot be solved by simply applying the existing technologies (e.g. current database and data management solutions). In particular, innovative information processing techniques are required, related to (i) measurement and adaptation to an unpredictable environment, (ii) spatial diversity and density of sensors, (iii) streaming data filtering, and finally (iv) mobility issues. The international community is working to create an open and standardized end-to-end architecture for automotive telematics services. This can be used to reduce the number of fatalities on the roads, as well as to provide traffic information or support entertaining applications. An example is the EU-funded Integrated Project Global Service for Telematic (GST Forum) with the definition of an environment in which innovative telematics services can be developed and delivered costeffectively [17]. In this paper, we focus on issues related to applications working on Vehicular Ad hoc Network (VANET), an emerging pervasive network [13]. A VANET is a wireless network formed on the fly among a collection of cars connected by wireless links, which has gained a great amount of attention during recent years for its use in a large number of safety (accident warning, weather notification) and non-safety (multimedia, gaming) applications. VANETs work under the assumption that each vehicle is equipped with at least a GPS receiver, a digital map, a transceiver, storage and processing capabilities. The GPS provides the latitude and longitude information that can further be mapped to a particular location using a digital map. The components of a VANET-enabled vehicle also include computer-controlled devices and radio transceivers for message exchange. The protocol that has been standardized for communication in VANET is DSRC (Dedicated Short Range Communications), with a communication range varying from 300 1. This work has been partly supported by a grant of the Italian Ministry of Education, University and Research, inside the ACIS project.
mts to1 km. Among vehicles, fixed roadside base stations (RSUs) provide information to the driver throughout his journey so that he can find the best route to his destination and avoid congested roads. The information exchanged in a VANET can be classified as (i) periodic messages (beacons or heartbeats) representing the status of the sending vehicle, (ii) safety or informative messages triggered by some event and diffused in a geographical region. The European CAR2CAR Communication Consortium (CAR2CAR CC), a non-profit industrial driven organization initiated by European vehicle manufacturers supported by equipment suppliers, research organizations and other partners, defines the beacons (or heartbeats) as specific case of single-hop broadcast, which are periodically sent by the CAR2CAR Communication Network Layer, thus allowing achieving cooperative awareness among vehicles. The content in bytes of these beacons is defined in SAE J2735 DSRC Message Set. In particular, beaconing is used to advertise the presence of a node to its neighbor nodes. Each beacon contains at least the node identifier and its timestamped movement information (position, speed, and heading). A beacon is sent periodically, typically every 300 ms, with an emitting power allowing a range of about 200300 m., however, in order to control network congestion, the beacon rate can be dynamically reduced when the network density is too high [3]. Various safety applications mandate such periodic broadcast beaconing of status messages, for example Cooperative Forward Collision Warning, Ad-hoc routing and geocast for urban VANET at application level. Moreover, new beaconing-based applications are emerging, related to security, assisted driving and traffic management. All these applications need to retrieve and analyze flows of beacons in order to raise the context awareness of the surrounding area. From a practical perspective, VANET applications can be modeled as a sort of “software sensors” which check for changing events in the flow of beacons. An efficient implementation of VANET applications has to take into account both the use of communication (e.g. Bandwidth) and computational (e.g. CPU) resources of the vehicle. The current state-of-the art on this subject is mainly focused on the bandwidth management in order to avoid congestion of the channel in case of high vehicular density. On the other hand, issues related to the efficient management of computational resources are more complex and open: for instance, solutions which grant an efficient access to the flow of beacons are required, taking into account both the congestion of the computational resource and the respect of priorities among different applications running on the same device. Usually, such issue is delegated to the middleware that is the main repository of data representing the dynamic environment of the vehicle. The middleware maintains the sensor data, information exchanged with other vehicles and static data, such as a digital map. Middlewares specialized in managing messages exchanged in a VANET are scarcely investigated. The aim of this kind of middleware is to provide context information for VANET
applications based on context awareness. In this field, some proposals have been made based on the Publish-Subscribe (Pub/Sub) model, basically aimed at supporting the management of alerting messages but not focused on the management of beacons which exhibit, instead, interesting peculiarities. To this regard, in this paper, we first perform an analysis on the state of the art on middleware that supports VANET applications. Then, we provide answers to the following questions, proposing suitable solutions: 1.
Which are the requirements of VANET applications aimed at analyzing the flow of beacons in order to recognize changing events in the context?
2.
Pub/Sub model is recognized to be an excellent support for programming event-driven applications. However, which kind of architecture and subscription language is more suitable, regarding the beacon flow analysis referred at point (1)?
3.
Performance is also an issue when there are many applications working concurrently and sharing the access to the same input data, as well as responsiveness with respect to real-time constraints. How can the issues related to real time, priority on execution and performance be handled?
Considering our proposed solutions to the above questions, we have developed a prototype Pub/Sub middleware called ACME ACis Middleware for Emerging vanet applications, to test its suitability in supporting a wide collection of safety vehicular applications. A brief description of the system is provided in the final part of the paper.
2. MIDDLEWARE FOR VA ET APPLICATIO S: RELATED WORK VANET applications are mostly event-driven, thus the Publish Subscribe paradigm is a suitable choice. Pub/Sub Paradigm allows to de-couple the role of publishers, which send messages, from the role of subscribers, that express interest in receiving only some kind of messages. Pub/Sub systems provide Brokers, that receive messages and subscriptions, filter the messages with respect to those subscriptions and deliver the messages to the subscribers as required. A Pub/Sub system is topic-based if the publishers define the classes of messages to which subscribers can subscribe, content-based if subscribers are allowed to define some constraints over the content of the messages in their subscriptions. A VANET middleware specialized for a Pub/Sub model implements functionalities able to support both the role of publisher and subscriber of any device. Regarding the first case, it provides functionalities for routing the published messages through the network. On the subscriber side, it parses information coming from the network and it sends the required ones to the subscriber applications. The events considered in the systems presented in the literature are the reception of short messages related to the notifications of warnings, traffic information, announcement of parking availability, and so on.
Another issue for those middlewares is related to the definition of a model for an overlay infrastructure and the event routing for the published messages. The event diffusion has been deeply investigated, an example can be found in [12], where the Abiding geocast is presented. In general, the focus is uniquely on information and alerting messages and not on the flow of beacons, even though they can be considered as a sort of messages. In this perspective, beacons can be seen as messages published in a 1-hop broadcast way, with information that can be of interest to any vehicle or RSU in the surrounding area. A different kind of middleware has been developed, aimed at collecting and managing data coming from different sensors in Wireless Sensor Networks (WSNs). Still, in those middewares, beacons are not explicitly considered as sensor data, moreover approaches developed for WSN are not easily extensible to VANETs, as shown in [6]. For example, a vehicle middleware in the VANET environment collects and processes data from internal sensors or coming from other vehicles through the wireless network in a centralized way, while in WSN data are monitored in a distributed way. Due to the unreliability of the WSN and of the sensor nodes, particular emphasis is usually given to space and energy efficient replication techniques, and, finally, sensor data are used in closed loop controls and could requires hard RT deadline, while applications using beaconing has Quality of Service requirements and execution priority in a soft real time execution environment. Thus, a simple extension of a WSN to a VANET environment is not possible due to both the variability of the kinds of possible queries coming from the applications (see Section 3) and the non periodicity of the beacon flow.
3. REQUIREME TS OF BEACO BASED VA ET APPLICATIO S We aim in this section to better investigate the applications based on beaconing technology. In particular, we will investigate the nature of the queries needed to efficiently support the applications, in order to classify them in similar groups. To this aim, we mainly focus on the requirements for accessing and managing flows of beacons. Other aspects, such as those related to priority and Quality of Service management, are not extensively considered here, even if our approach allows to handle those issues in a simplified way. Important and well known safety applications are beacon based, for example the Cooperative Collision Warning application, where a vehicle actively monitors the status of the vehicles in its neighborhood to warn of potential collisions, and the Cooperative Violation Warning application, where a road-site unit actively transmits information to approaching vehicles, so that the driver can be warned of potential violation of traffic signals. Other applications make use of geocast and geounicast, implemented using information received by means of beacons. More recently other beacon-based applications have been proposed, related to security, traffic management and assisted driving.
Interestingly, an application aimed at verifying the security in a VANET can check whether nodes send false position information in their beacon messages, due to malfunctions or even malicious behaviors. In [10] different approaches are considered, for example the Maximum Density Threshold, based on the assumption that only a restricted number of cars can reside in a certain area, or the Mobility Grade Threshold method, based on the assumption that nodes can move only at a well-defined maximum speed. Another promising area where VANET and beaconing can prove to be very useful is Traffic Management, where various approaches have been tried, ranging from those requiring assistance from roadside infrastructure to purely infrastructureless approaches [20]. Since there is a relationship between traffic density and vehicle velocity, vehicles can locally evaluate changes in the surrounding vehicle flows using beaconing, aggregate traffic information in reports, and finally diffuse them using intervehicle communication. Cooperative Adaptive Cruise Control (CACC) is a traffic efficiency application attempting to maintain a constant vehicle speed using a combination of radar or camera sensors, and receiving beacons from vehicles ahead of it [5]. This information is used to set up a platoon of vehicles with safe spacing between each vehicle, where each car is continuously monitoring throttle and speed changes of the vehicles behind it. Considering the requirements of all those applications, it is possible to characterize 3 different types of queries, described in the following, using case studies.
3.1
Geocast in urban environment
In a VANET, the geographical routing protocols are preferred with respect to the usual IP based forwarding. Such protocols do not establish routes, but use the geographical position of the destination to forward data, knowing the positions of the neighbor nodes to be used as relays. The CAR2CAR CC considers the Geocast as a core network concept for the future vehicular network, and proposes its implementation at network layer, using the geographical information exchanged by means of beacons. A basic algorithm for unicast is the greedy forwarding, which allows the maximum progress within radius (MFR) policy. However this approach does not work well in urban environments, where road-based routing protocols outperform it. The problem is that often, due to the traffic limitations posed by the city layout and to the radio obstacles, the protocol cannot find a vehicle closer to the destination than the current vehicle, and a recovery strategy must be applied. The knowledge of the vehicle positions over the roads and of the city map allows to create road-based paths consisting of successions of road intersections. Moreover, having also at disposal real-time vehicular traffic information, it is possible to select the road path with the higher connectivity and stability [15]. In order to implement this class of street-aware protocols, beaconing is required (as well as with the other network geocast protocols), but the geographical position of a vehicle must be mapped on the street map to recognize vehicles useful for the routing.
3.2 Detection of the variation of a beacon parameter In the previous case, the knowledge of a single beacon at a time is sufficient. In other situations, the crucial information rises, instead, from the variation of a value (e.g. speed, positioning) between two consecutive beacons of the same vehicle. For example, some applications need to be aware of the transit of the ego vehicle, that is the vehicle where the applications are running, through a given position on the road. Such information is generally used for traffic analysis or to collect information regarding the specific road. Usually the traffic analysis is performed using inductive loop sensors. Such sensors register whenever a vehicle transit over them, and can be used to determine aggregate flows and volume information on road segment as well as to provide estimates of vehicle speed. They are used to monitor specific portions of roads by placing them at sites of interest, for instance positioning two sensors (referred to as “upstream” and “downstream”) on either side of the road segment to be monitored. Such data streams are collected and relayed back to a Traffic Center, where they are aggregated into counts of vehicles and average speeds. Beacons can be used instead of inductive loops, thus avoiding the installation of physical sensors. In [19] a Pub/Sub system supporting an RSU safety application is analyzed: the RSU is placed in a crossing and provides information to the surrounding vehicles on waiting time, velocity and density, collecting data, for example from inductive loops.
recognize malfunctioning node sending incorrect beacons. These approaches require the evaluation of average values on the set of collected data from beacons as the total number of vehicles on the road or the average speed. The idea to aggregate the received messages to allow a later evaluation is exposed in [16], where the information messages diffused through the VANET are aggregated once they become obsolete, instead to delete them, in order to produce additional knowledge useful for the driver. Sensor data aggregation is also used in traffic and mobility management in order to discover congestion. However, in sensor networks nodes are usually fixed, and periodic evaluation can be performed, such as counting input data, while in VANET nodes have high mobility and traffic could exhibit high variations. Also in this case the use of beacons supports more fine-grained analysis, allowing the distinction of data coming from different vehicles. For example, in application for driving assistance it is possible to monitor the changing of a given parameter, like speed, only for vehicles preceding the ego vehicle. The mapping of the geographic position on the street map is required, with some form or stateful query support in order to evaluate aggregated data. In general, considering the previous analysis, the use of beacons can efficiently support the current state-of-the-art in VANET applications if beacons are extended with road information, and if the subscriptions can be performed considering: Single beacon arrival, like in the urban geocast algorithm. Variations of some status parameter in 2 successive beacons.
Inductive loops can be easily substituted with “software sensors” able to recognize the transit of a vehicle across the endpoints of the road segments. Remark that using beacons, more accurate information could be provided, for example statistics on the direction of traffic flows, by isolating the single vehicle trace through the use of the beacon it broadcasts. In some cases, the transit through a point of a road segment concerns the ego vehicle and can be recognized through RFID sensors placed along the road. However, data arriving from the GPS enriched with speed and compass direction can be viewed as beacons related to the ego vehicle, so also RFID could be substituted with a software sensor. An example of application able to exploit this feature is described in [20], where techniques for traffic analysis and broadcasting of geolocated messages are presented [11]. In the previous cases, the interest is in the variation in the position of a vehicle, but similar applications exist, which consider the variation of other state parameters, such as speed. In all these cases two functionalities should be provided by the middleware: (i) the mapping of the geographical position on the street map in order to consider only the vehicles on the selected road, and (ii) the evaluation of the variation of some beacon parameter between 2 consecutive beacons of the same vehicle.
3.3
Data flow aggregation
As already discussed in [10] different approaches (e.g. Maximum Density Threshold, Mobility Grade Threshold method) are considered in order to prevent the so-called Sybil attack (where nodes send in a malicious way false beacons) or simply to
The result of some function defined over aggregated beacon flows (e.g. traffic analysis, platoon management).
4. FEATURES OF A BEACO BASED PUBLISH-SUBSCRIBE SYSTEM The conventional technique used by Pub/Sub systems for satisfying the user requests is typically stateless, since queries are evaluated every time a new data is received, considering only the last received message.
4.1
Stateful subscriptions
The requirements of VANET applications examined in Section 3, take the stateless approach insufficient for evaluating variation of beacon data or functions over beacon aggregations. In fact, these kinds of operation require that the Pub/Sub model could be stateful. Similar approach can be found in the so-called Continuous Queries systems, such as TelegraphCQ [4], NiagaraCQ and others, mainly for general use. CQ systems arose out of the database research community, but they are not really data base systems, even if they share some of the relational database concepts. In traditional database a query is applied once to the content of the database, while in CQ system the queries are always
active. Then, data flowing through the continuously executing queries have to be transformed in data flows out to applications. These systems are based on SQL-like language, they are applied to complex event processing and work on sequences of events on a single stream or on multiple streams. When dealing with Continuous Queries language, where sensor data are recorded in a suitable repository, the most important feature is the aggregation capability, namely the ability to parse and merge different streams of data to evaluate a function related to the query. Time windows are defined over the streams, namely upper-bounding the amount of data to aggregate for each stream. An example of application can be found in [2], where an extension of the language SPARQL to support continuous queries over data streams is presented. The following example shows a query related to the evaluation of the number of cars entering the city passing through tollgates in the last 10 minutes, sliding the window every minute.
While taking into account these differences, the CQ systems provide some ideas useful for the stateful evaluation of subscription queries.
4.2 Subscription language and performance considerations With respect to performance of a Pub/Sub based middleware, the main feature of beacon-based applications is the large amount of data that are exchanged through the ad hoc wireless communications. The requirements of the VANET applications are related to aspect of Quality of Service, soft real time deadlines, priority management and functional features such as flexibility (the ability to make decision at run time) and extensibility (the ability to allow easy extensions, for example adding new software sensors and new messages). Real Time Operating System is not really required in order to comply with strict deadlines, because the bursty and not predictable characterization of the communications and the eventdriven property of the related applications would make hard to realize a pre-ordered management of the RT scheduling.
However, the management of beacons exhibits different characteristics. First of all, in CQ systems the number of sensors producing data is limited, while the stream output by each sensor is theoretically infinite and stored in a relational database. Regarding beacons, a stream is infinite only if it regards the aggregation of all beacons coming from different vehicles, while, from the perspective of single vehicle, acting as an individual sensor, it is more reasonable to take into account a limited number of beacons, since application interest focuses on vehicles which are in the area surrounding the ego vehicle or RSU.
The run-time system must be able to take into account priorities in order to keep active only the queries that are prior against the variation of the beacons arrival rate, and to throttle the threads of the application associated with the notifications. All these issues are difficult to manage if applications are independent (i.e. applications access separately the beacon data and make calculations individually). On the contrary, if access to data and calculations are made by a common, single and centralized middleware for all applications, these problems can be tackled in a simpler and more controlled way.
On the contrary, the number of sensors, that is vehicles, is theoretically infinite, since the number and kind of vehicles on the roads changes dynamically and continuously.
Summarizing the characteristics required to a Pub/Sub based middleware for VANET applications, the following points emerge:
Beacons coming from vehicles out of neighborhood of the ego vehicle or from the past are not useful, except for statistical applications that do not execute in an event-driven mode. Thus, it is necessary to keep in the repository (which grants a stateful behavior) only the beacons coming from vehicles still in proximity of the ego vehicle.
The need of dispose of subscription queries expressed in a stateful and stateless form, and thus the need of a repository in order to keep track of the received beacons,
Furthermore, the number of beacons stored can be reduced by ignoring vehicles moving for example on parallel roads or bridges over the ego vehicle, since a VANET application is only interested in beacons concerning the electronic horizon of the ego vehicle. Finally, while the main focus of CQ systems is to define a window over the streams, in VANET applications the performance is a more important requirement. Thus, it is fundamental to define functions associated to aggregation of beacons in an incremental way, in order to avoid to newly evaluate the function at the arrival of any new beacon, since they must continuously provide results.
The repository of beacons is temporary and it keeps track of beacons coming from the proximity, in time and space, of the ego vehicle. A further reduction of the beacons in the repository both introducing a window for the computation of the stream queries and taking into account the vehicle on the electronic horizon of the ego vehicle. In order to increase the reactivity of the system, the functions associated to subscriptions have to be calculated incrementally on data in the repository. A possible way is to pre-define basic functions possibly needed by the applications, like the number of vehicles, the average speed, the maximum or minimum value of a parameter in the beacons. The query language has to
5.
support also the possibility to filter data, for instance, based on the road and on the direction of the vehicles.
needed adaptability to changing network conditions and system platforms by means of plugins.
Characterization of priorities in subscriptions according to the required QoS.
In particular, the ACME PosProvider receives beacons from the surrounding vehicles and the data from the GPS (or other positioning system) of the ego vehicle, and produces the related XML documents (i.e. the ContextPosition items), containing the input information. Therefore, it acts as a publisher of such information.
THE ACME PROTOTYPE
ACME, ACis Middleware for Emerging vanet applications, is a middleware compliant with the CAR2CAR CC proposed platform, which supports both the delivery of message through RSU or through the VANET built among vehicles, and the broadcast of beacons containing vehicle information. ACME provides a content based Pub/Sub system which supports stateless and stateful queries over VANET messages and beacons.
The core services of ACME, developed as a Java library and distributed under GPL3 license [1] are PLS, SECR, ENS. Figure 1 shows the UML Composite Diagram of the system.
ACME development has been planned in two phases. The aim of the first prototype, here described, is to provide a proof of concept of the usefulness of the solutions proposed in Section 4 for the development of a Pub/Sub based VANET middleware. Presently ACME supports beaconing based applications, to be used as tests for the notification system. For these reasons ACME core services have been developed by extensively using existent Java libraries, and concentrating, instead, on the design of the services and the management of stateless and stateful subscriptions. In order to support heterogeneity of software platforms, XML has been chosen to encode the message and beacon content. XMLencoded messages exhibit a hierarchical and flexible structure that allows to submit rich queries. For XML queries, filtering systems exist which allow users to perform queries written using path expressions that can specify constraints over both structure and content of XML messages, applied to individual messages. However, their answer is a simple boolean, since they do not provide customized result delivery, useful for XML-based data exchange and dissemination. Instead, ACME queries are expressed in XQuery [21], a subscription language that supports XML transformation by means of the For-Where-Return expressions. Moreover, XQuery allows to keep up-to-date the value of predefined variables concerning the internal status of the ego-vehicle, namely: identifier, positioning data, speed and current time. During the parsing of the query, if the system notices the presence of a recognized variable in the query, the value of the variable is modified with the current one. We adopted Nux, an open-source Java toolkit for querying XML documents in first-level memory [16], for implementing continuous queries.
Figure 1: UML Composite Diagram PLS-SECR-E S system PLS - Positioning and Localization Service, receives the ContextPosition items and maps the positional reference, provided in longitude and latitude, on road data, enhancing the information carried in the beacon and keeps track of the electronic horizon of the ego vehicle. The current version loads OpenStreetMaps containing an XML representation of the ways, described by means of node positions and other associated entities. Two nodes delimit an edge, and a chain of edges describes a way, defining its shape. SECR - Spatial Environment Context Repository, keeps track of all context data, generally defined ContextItems, including the ContextPosition items. SECR uses its Control Access Module for answering to synchronous queries, allowing an atomic insertion of ContextItems. The repository resides in the short-term memory of the system and stores time and space related data related that are valid in relation to the position and state of the ego vehicle.
Applications must register their subscriptions together with an XQuery expression and the associated update method. ACME will notify all observers of an event's occurrence, in the form of an invocation of their update methods.
E+S - Event +otification Service, supports the operations of publish(), subscribe() and unsubscribe(), keeps track of the application subscriptions and provides the notification of events required by the applications, both in stateful (using data recorded by the SECR) and stateless mode.
Each update method runs as thread, in order to be handled separately from processing notifications, thus allowing to dynamically alter the performance characteristics. ACME architecture draws upon the design of Contory [17], a middleware for the management of sensor data, based on on ContextProvider modules, one for each kind of input data, in order to provide the
In Figure 2 an example of ContextPosition, where the field tagged has been added by the PLS, is shown. In order to set the position of a vehicle on a road independently from the particular input map representation, additional objects, called roads, have been added.
A road R is a segment of a way, composed by a collection of linked edges, connecting two consecutive junctions (or one junction and a dead-end street). A road has an internal representation from the first to the second junction R(J1, J2), so that the real heading of the vehicle can be redefined referring to such order, that is: 1 if the vehicle is going to the first junction, 2 on the contrary. Moreover, the distances D1(V) and D2(V) of the vehicle from the 1sr and the 2nd junction is added, to correctly position the vehicle on a road. A point X on a map can then be indicated as P1(X, R) = (D1(X), R(J1, J2)), or, respectively P2(X, R) = (D2(X), R(J1, J2)).
Periodically, SECR carries out a control of validity on the lastinserted ContextPosition of each vehicle. Each such item is recognized as valid if it has been generated in the last three seconds. After this period of time, a couple of beacons, the second one with NULL data, is generated and delivered to the Query Engine of ENS, to notify the exit of such vehicle from the neighborhood.
6.
CO CLUSIO S
In Intelligent Transportation System applications an important kind of communication to maintain context awareness is the periodical transmission of short status messages or beacons. In such a way beaconing support the concept of cooperative awareness. This paper is motivated by the fact that a systematic and thorough analysis of event driven applications using beaconing from the point of view of the middleware requirements is still lacking. For this, we performed a preliminary study to better understand the requirements of such applications and the functionality that a Pub/Sub middleware must provide to support them.
Figure 2: example of ContextPosition outputs by PLS Such representation allows to easily characterize the transit of a vehicle V with direction =1, through a point X, positioned in P1(X, R). Knowing 2 consecutive beacons of V, two measurements P1'(V, R) and P1”(V, R) are obtained. Then when the condition D1'(V)
