PLUGAM: Plug-in based Adaptation Middleware for Network Layer Protocols for Vehicular Ad Hoc Networks

—Vehicular communication environments are characterized by highly mobile nodes, frequent topology changes and a great variation in the number of neighbor vehicles. The Network layer (NL) protocols must adapt continuously to these unreliable conditions, hence the growing effort in the development of protocols speciﬁc to vehicular networks. The aim of this work is to help create vehicular systems with an adaptive Network layer, by means of proposing a middleware based on an adaptation model and using as input the context information of the vehicle. The architecture will build an adaptive Network layer using two types of run-time adaptations: modiﬁcation of a NL protocol internal parameters and adaptations where a selection between NL protocols must be made. To assess the feasibility of our approach we present two case study examples and present a ﬁrst prototype. In addition, we brieﬂy evaluate the adaptation presented in case study 1 via simulation, we found that it produces 20% less control overhead. Furthermore, we present an analysis of the prototype performance to get a rough idea on the cost of using the middleware in the vehicular system; results show that it’s feasible to implement the middleware in hardware similar to today’s mid-range smartphones.

in network conditions make the design of Network layer (NL) protocols difficult and complicates the development of applications that require efficiency under the dynamicity of these network conditions.Hence, routing protocols must adapt continuously to these unreliable conditions, thus the growing effort in the development of communication protocols which are specific to vehicular networks.Schoch et al. [1] mention some key VANET network conditions like network density, node speed, node heterogeneity, movement patterns; the authors highlight the extremely opposite values that these network conditions can get in the course of the network's lifetime; for example the node velocity may range from zero for stationary road side units, or when vehicles are stuck in a traffic jam, to over 130 kph on highways.For us these characteristics can be seen as context information useful for the Network layer protocol.Some authors [1], [3] state that potential vehicular applications require different communication or types of Network layer protocols that exist in the literature to optimize communication.For example, applications like post-crash or breakdown warnings are adequate to use geobroadcast or information dissemination protocols, because the information has to be delivered as quickly as possible to a subset of surrounding vehicles.On the contrary, applications like Internet connectivity and road surface conditions to traffic authority center are not well suited to use dissemination protocols, because the destination of the message is of great importance and one-to-one communication is desired; in this case, using unicast routing Network layer protocols seems more adequate.
We think that having a vehicular system that supports most of these potential applications will help promote the adoption of a real world VANET technology by offering a wealth of services that encourages the driver to go premium and get the on-board system in their new vehicle or mitigate the investment of buying and installing the on-board module in their current vehicle.Nevertheless, for this to work, each application's underlying NL protocol must maintain a good performance in spite of the changing network or even applications conditions.There could even be a case in which for an application to maintain good service performance, adapting the NL protocol is not enough and requires the use of different types of NL protocols.
In reference to the applications requiring different communication protocols, authors like Schoch et al. [1] have proposed having a network stack with a set of different network protocols to satisfy all the different applications needs.Schoch et al. also proposed a set of NL protocol types (refered by them as communication patterns) that they think will be enough to support most of the vehicular applications in the literature.Some of these protocol types are dissemination, unicast and carry and forward.Some other authors have made different categorizations of NL protocols, for example in [4] and [3].From the point of view of integration of the vehicular systems of the automotive makers and the research and academic projects, we think that at least two NL protocols are needed in the vehicular system: an unicast NL protocol to enable V2I communication for the info-entertainment applications and a dissemination NL protocol to enable V2V communication for security on the road applications.
Exploring the state of the art in NL protocols in VANET, we notice that the dynamic aspect problem of a VANET is too vast and proposals only attack part of the problem.These proposals focus on adapting to specific context information or network conditions, optimize for specific scenarios like highway, city, low density network, etc., and tailored for using a specific NL protocol.In addition, even when all the proposals solve the dynamic network problem using some kind of adaptation solution, they all use different concepts and terminology to describe their solution.For example, we can find proposals using concepts like hybrid protocol, adaptive protocol, context aware protocol, reflective, autonomic, self-manage, policy based, etc.This use of different concepts and terminologies complicates the comparison between proposals, reuse and generalization the adaptation ideas.Another observation of the state of the art, is that we identify a need for vehicular systems using more that one type of NL protocol to support more vehicular applications instead of trying to find one that serves for all.Moreover, we think that there could be situations in which the application can select what NL protocol to use depending on the current context or to switch to using a different type NL protocol went the current context makes the default NL protocol perform poorly.
Based on the previous problem context, we have the strong conviction that a future Network layer that could truly satisfy the needs of potential vehicular applications and deal with the dynamicity of a VANET, must have the following functionality: • Support multiple types of Network layer protocols, in addition allow adaptations where there could be a selection on which protocol to use based on context decisions or switch to using another NL protocol when the current context generates poor performance.• Have Network layer protocols with the ability to adapt their internal parameters based on the current context.
That is why the focus of the present work is to propose a middleware architecture to help create vehicular systems with an adaptive Network layer.This architecture is a generic approach as it will build a subset of adaptive NL protocols found in the literature, and because the architecture must be instantiated by adding the modules to provide the context information, the NL protocols and vehicular applications required to build the desired vehicular system.The architecture will be able to build an adaptive Network layer using in general two types of run-time adaptations: modification of internal parameters of a NL protocol and adaptations where a selection between NL protocols must be made, both of these adaptations will use as input the context information of the vehicle.The core ideas of our adaptation middleware architecture can be summarized in the following points: • Propose a model of the adaptation concept.
• Propose a design methodology to build the adaptations in the architecture by dividing the solution into sub-modules (components) which are independent of each other, and then combine them by describing their relationships to form the adaptive Network layer.• Propose a multiple applications-multiple NL protocols environment.
The rest of the paper is organized as follows: we start by describing the adaptation model used by the architecture.After that in section III we present in detail the architecture for the proposed adaptation middleware.Then, in section IV we present some case studies examples and how they are implemented in our architecture.In section V we describe how we implement a first prototype of the adaptation middleware.We proceed in section VI with the evaluation of our adaptation middleware which focuses on evaluating the performance of one of our case studies examples and presenting an analysis of the cost and performance of the prototype.Then, we present the related work in adaptive NL protocols and other architectures that promotes adaptation.Finally, section VII contains conclusions and possible future work.

II. THE ADAPTATION MODEL
Prior to the description of the adaptation middleware architecture we will present how we modeled adaptations with a focus for NL protocols, this adaptation model will be the core of the architecture.
The adaptation concept refers to the ability of a process or entity to dynamically alter its behavior during its lifetime depending on the changing conditions of the environment.In computer software the adaptation term appears in subjects like adaptation of the video quality depending of the network connection [5], adaptation of the GUI of an application based on the display resolution of the device [6], reconfiguration of the components forming a system [7], [8], etc.There are also some other topics in computer science that center on the idea of adaptation, for example the term of computational reflection, dynamic aspect oriented programming, policy middlewares, and autonomic computing.In our work we refer to the adaptation of the Network layer of a vehicular system, this means that the process or entity that will be adapted is the NL protocol.
In regard to adaptations in communication protocols, Grace et al. [9] distinguishes between two distinct classes of adaptations: In node-local adaptation, the adaptation triggered by a node only involves changing the behavior of itself.In distributed adaptation, an adaptation triggered by a node involves changing the behavior of itself and other nodes in the network.An example of a distributed adaptation is the dynamic reconfiguration of sensor networks proposal of Grace et al. [9].Distributed adaptations are more complex because they have additional challenges to take into account; for example proposing a consensus mechanism for situations when multiple nodes perform a distributed adaptation with different results due to the different local context information.Other additional challenges are the need for a notification and scheduling protocols in order to perform the adaptation operation in all participants.Finally special care is needed to avoid performing conflicting adaptations that can render unexpected results.In the case of our work, this version of the architecture is only focused in dealing with nodelocal adaptations; extending the work to support distributed adaptations will be considered as future work.
Grace et al. [9] also identifies two kinds of general approaches to software adaptation: parameter adaptation and compositional adaptation.Parameter adaptation modifies pre-defined program variables that determine a systems behavior, there is no introduction of new algorithms and behavior.Compositional adaptation allows the dynamic re-composition of software modules to change or introduce new behavior.Our adaptation middleware architecture falls into the parameter adaptation approach of software adaptation.
After describing the adaptation concept, we proceed to the description of the adaptation model.Foremost, from now on we will refer to any NL protocol proposal that adapts in this manner, even previously proposed works, by the name of "adaptive protocol".The adaptations inside these adaptive protocol proposals take as input the local context information from the vehicle.
A key point of the adaptation model is the idea of separating the functionality of an adaptive protocol into two independent parts.One part is the Network layer functionality of a protocol, for example the definition of messages format, message sending/receiving operations, suppression mechanism for repeated messages, topology update, connection to upper and lower layers, etc.We think this is the biggest part of an adaptive protocol because the development of a network layer protocol is very complex.The second part is the functionality that performs the specific adaptations in the protocol that enhance it and make it more dynamic, we named a specific adaptation in the protocol as an "adaptation solution"; an adaptive protocol could have multiple adaptation solutions that enhance the protocol.This idea relies on the separation of concerns principle [10], a general principle in software engineering that promotes the separation of different interests or concerns in a problem, solving in separate modules without requiring detailed knowledge of the other parts, and finally combining them into one result.For us, the two concerns to separate are the adaptation solution functionality and the Network layer protocol functionality, and by solving them separately our model will offer a mechanism to combine them to form a complete solution which in our case is the adaptive protocol.
The adaptation model also proposes the separation of the adaptation solution concept into sub-concepts (named by us as adaptation elements) and the description of their relationship.Applying again the principle of "separation of concerns", the adaptation solution is divided into three elements: • Context element: Symbolizes a piece of information about the environment which is used as input to produce an adaptation solution.This concept also encapsulates the instructions or code that manages and provides this context information in order to be used for the adaptation.This is similar to the concept of metric from the works of Boleng et al. [11] and Yawut et al. [12], however we decided to use the simpler word element instead of metric.• Adaptation algorithm: Encapsulates the instructions, logic or operations that uses the adaptation solution, which is based on the context elements to produce an adaptation as a result.This is also similar to the concept of "policy" used by Hazic et al. [13].• Adaptation action: Symbolizes a characteristic, element or action that the adaptation solution modifies, activates/deactivates or does as a result of adaptation solution.This is similar to the concept of "mechanism" of Hazic et al. [13].
The separation of the adaptation solution in these three concepts further promotes the modularization of the adaptive protocol.A second benefit is that it facilitates the comparison and classification of prior works by observing the adaptation elements used by them.Finally this separation could enable a rapid calibration of an adaptation by simply exchanging of adaptation elements in it until a right combination produces a desired result.
The relationship between the elements of an adaptation solution is modeled as an algorithm with inputs and outputs (1).
The adaptation algorithm takes as input a list of context elements, their values are used by the instructions and operations inside the algorithm, the current value of the context elements are collected from the context environment when the input list is constructed.The adaptation algorithm produces as a result a list of values for the associated adaptation actions.Finally these values are transmitted to the adaptation actions entities that modify the behavior of the adaptable process based on these values.
Another aspect of the adaptation model is the definition of where or when in the process will an adaptation solution be executed.We named these places or points of the process as "adaptation modes".For example, for a NL protocol, some places or points to execute adaptation solutions could be when a node receives a message, when the routing table is modified, every T seconds, when some context elements conditions are met, etc.Our adaptation model defines a set of adaptation modes which are specific for each type of process wanting to adapt.Hypothetically a more general and flexible adaptation model could allow adaptation modes to be in every point/place in the process (e.g. in [7]), however we think this entails changing the way the original process works internally to be able to support this functionality.In the case of Network layer protocols, it will surely be required a complete re-implementation of a protocol, and this is not an easy task.That is why we opted to having only a set of adaptation modes, in hope that a proper selection of the adaptation modes can surely diminish the task of porting an already implemented NL protocol in the literature.
The last aspect of our adaptation model is how the network layer protocols are integrated into the adaptation solution concept and its elements.The NL protocol is tied to the adaptation action concept, a NL protocol will offer a number of adaptation actions to allow adaptation solutions to change its behavior via changing the value of the adaptation action.Moreover, there will a handful of special adaptation actions that are not associated to a specific NL protocol but instead are offered by our middleware; we will talk more about them in later sections.In Fig. 1 we show the relationship of all these adaptation elements described in an Entity/Relationship model.

III. PLUGAM ARCHITECTURE
In this section we will describe the architecture of the proposed adaptation middleware called PLUGAM (PLUGin-based Adaptation Middleware), this architecture is based on the adaptation model described in the previous section.This description will be guided by explaining the key aspects of the architecture; first we will present an overview of the PLUGAM architecture and the details will be described in the following sub-sections.
The objective of the PLUGAM middleware is to propose a generic architecture to build a set of adaptive protocols.The adaptation solutions embedded in the adaptive protocols are built using external and independently developed components, called "extension components" in the architecture, loaded in the middleware at startup.The extension components defined in the architecture are the adaptation elements (context elements, adaptation actions and algorithms), the applications and NL protocols.After loading all the extension elements needed to build the desired adaptation solution, the next step is to express the combination of the extension components forming an adaptation solution; i.e. the adaptation algorithm used, the context elements that will the inputs to the algorithm, the adaptation actions that will be tied to the outputs of the algorithm, in what adaptation mode will the adaptation solution be executed, among other things.To express this combination an "adaptation configuration" must be created in the middleware (see section III-F for more information).
The architecture makes use of plug-in technology as a mechanism to encapsulate and load the extension elements to the middleware; the relationship between the different types of plug-ins and the extension elements offered by these plug-ins is described in section III-D.Our proposed architecture also includes a mechanism to uniquely identify an extension component from all others, even from others of the same type (e.g. between NL protocols or context elements).The main use of this identification mechanism is to reference what extension component is required in each field of the adaptation configuration, among other uses that we will see in detail in section III-E.
As mentioned in the adaptation model section, an adaptation mode is a place or point of a NL protocol where an adaptation solution is executed (see Fig. 2).We proposed to use four adaptation modes: send, receive, forward and CUPIB.The send, receive and forward modes are in reference to the events between an application and NL protocol; for example send mode refers to the event when the application calls the send command and the message must be directed to the protocol.The CUPIB mode is not tied to an application and NL protocol event, but rather is a mode that executes the adaptation solution at a certain period of time.A detail description of these adaptation modes can be consulted in section III-C.
As shown in Fig. 2, we modeled an adaptation solution as a module containing an algorithm, which receives as input a list of context elements values, and produces as output a list of values used to execute adaption actions which are parametrized with these values.Before executing an adaptation solution the architecture will retrieve the current context element values from a context environment defined in the architecture.This context environment is made by different context sources offering context elements; more details on these context sources and the definition of a context element can be found in section III-B.Referring to the adaptation actions, apart from the adaptation actions offered by the NL protocols, the architecture offer two special adaptation actions: the "switcher" and the "filter", more details about these special adaptations actions is presented in section III-H.
Finally, in this architecture the Network layer is compose of multiple NL protocols, all of them executing concurrently at run-time; this is different from a common network stack in which there can be multiple applications in the Application layer but in the Network layer there is only one protocol.In this multiple NL protocol enviroment an application needs to subscribe to multiple NL protocols at initiation, then at run-time it can send and receive messages from these NL protocols.A more in-detail description of the role of applications in the architecture can be seen in section III-I.This concludes the overview of the PLUGAM architecture, from here on we will describe the details of the architecture, starting with the characterization of the intended user of the middleware.

A. The user of PLUGAM middleware
This middleware is intended to be used by the automotive maker developer which is building the on-board vehicular computer with VANET capabilities, 3G, etc.It is not intended to be used directly be the driver.This middleware will be a development tool to help the automotive maker develop more dynamic vehicular applications by having an adaptive Network layer in the vehicular system.Below we present a characterization of these automotive vehicular systems.
The development of complex vehicular systems by the automotive maker is a recent trend, they are refered to as "incar technology" in the automotive business.Some examples of these systems are Toyota Entune2 , Ford SYNC3 and MyFord Touch 4 , Renault R-Link5 , Nissan NissanConnectSM6 .These are closed proprietary systems, incompatible with other vehicular systems of other brands and even from different models of the same brand.
Most of these systems provide a little touch screen in the vehicle's dashborad to provide output and input, and their hardware specs are similar to embeded systems of smartphones.Furthermore, these systems can be updated via USB flash drive either at the automotive dealer or by downloading the update to the USB drive.Recently, some automotive companies are starting to provide over-the-air updates to the software of their on-board systems, for example the Tesla Model S vehicle 7 .

B. Definition of context environment in the architecture
The adaptation middleware architecture uses the concept of context to refer to the input information used by the adaptations solutions.From Salber et al. [14], the definition of context refers to the environmental information that is part of a systems operating environment and that can be sensed by the system.
For the adaptation middleware architecture we define the context of a node, or the context environment of the middleware, as a collection of "context elements".A context element can be provided by an entity inside the node or middleware, called a "context source".In the architecture we view a context source as a independent module running concurrently and supplying the current value of the context element it offers.At run-time the middleware will take charge in retrieving the current value from the context source either via polling or publish and subscribe mechanism.The architecture defines four context sources: An NL protocol, an application and finally entities that offer local-node context elements (e.g.information from a GPS or an automobile sensor), each context source could offer multiple context elements.
Each context element has meta-information associated to it like a name, the data type of the context element, etc.At run-time, at a given time t, a context element CE has a value CE(t), which can be retrieved by querying its context source.At run-time a context element value is encapsulated by the ContextElementValue class, which contains a name field to store the name of the context element, the value field to store the current value of the context element (to be able to store any data type in java an Object class is used), and a type field to store the data type of the context value (in java a Class class is used).
A context manager module in the middleware handles the retrieval of the current context element value from the source via either the polling or publish and subscribe methods, concurrently to the execution of the adaptation solutions.The PLUGAM architecture is flexible by allowing the context sources to offer the current values only by the polling method, and implement the publish and subscribe method optionally; the context manager favors using the publish and subscribe method if available.The context manager stores the current values of the context elements in an internal direct access memory structure (e.g.hash tables).
The idea is to always have an up-to-date context environment, thus at the time when an adaptation solution is executing and it needs the latest values of the context elements, the context manager simply gets these values directly from the context manager direct access structure, instead of going to the context source to get the current value.We adopted this context element values scheme to generate a minimal processing time in the execution of an adaptation solution.However, it opens the possibility of getting a not up-to-date value of a context element at the moment when the adaptation solution is being executed.
The processing overhead of the context manager can be reduced by using the publish and subscribe method because the architecture already assumes that the context sources are concurrent entities.In addition, favoring the publish and suscribe method instead of polling avoids getting non-up-todate values of context elements, because the context source immediately informs the context manager when the value changes.
For critical adaptation solutions that depend on the most updated value of the context elements to work correctly, we can trade up-to-datedness for processing time by extending the adaptation configuration definition.This extension involves adding a Boolean type flag named GetInmediateValue alongside the context element field in the adaptation configuration.This flag will be used at the moment the adaptation solution is being executed and getting the current values of the context elements; if the GetInmediateValue flag is true then the middleware does not get the current value from the context manager, but instead goes and retrieves the value by directly querying the context source.

C. Definition of the adaptation modes
As we mentioned earlier, the concept of adaptation mode refers to where or when in the process will an adaptation solution be executed.In order to produce adaptations involving a multiple protocol Network layer and adaptations that change the NL protocol internal parameters, in this version of the architecture we define four modes of adaptation, these modes are: • Send: An adaptation can take place the moment the message is sent, in between when the application calls the send command and before arriving to the Network layer protocol.• Receive: An adaptation can take place the moment the message is received, in between after the NL protocol delivers the message to the upper layer and before the application actually receives it.• Forward: An adaptation can also take place the moment the message is forwarded, meaning when the protocol receives a message from another node to relay it, just before it will resend it to another node.• CUPIB: Finally the architecture supports the CUPIB mode (Continuous Update of Protocol Internal Behavior) used for adaptation of behavior inside NL protocols by periodically executing the adaptation solution.
To further understand the send, receive and forward adaptation modes, Fig. 3 shows their location in regard to the end-to-end path of a message passing through the Application and Network layers.3 . Placement of the send, receive, forward adaptation modes from the message end-to-end path between the Application and Network layers These adaptation modes were deducted from examining prior adaptive protocols proposals: For example in [15] the authors perform adaptation from the receive Network layer operation, in [2], [15] the authors perform adaptation in the forward operation of a Network layer protocol, in [16] the authors perform adaptation in the sending of the messages in the NL protocol.Finally the work in [17] performs adaptation to NL protocol by updating an internal behavior of the protocol and reevaluating with a certain frequency.
The CUPIB mode is especially useful for extending already implemented protocols where a constant can be tweaked to adapt to some context conditions.By creating an adaptation solution in the CUPIB mode and linking the protocol variable to an output adaptation action, the adaptation middleware will automatically take care of updating the protocol variable at run-time by periodically executing the adaptation solution.The adaptation solution is re-executed at a certain time interval defined in the configuration of a CUBIP mode instance.In addition, thanks to the definition of an adaptation solution, which allows associating multiple adaptation actions as output, it is possible for a single adaptation solution in CUPIB mode to update various NL protocol variables even from different NL protocols.

D. Encapsulation of the extension components using plug-ins
Back in the adaptation model we separated the concept of adaptation solution into the contexts elements, the adaptation algorithm and actions.Moreover, the architecture proposes a separation of the implementation of these adaptation parts, in addition to the implementation of the applications and NL protocols; in this manner all of them can be developed separately and independently.We named these independent modules as the extension components of the middleware.For this purpose, we have chosen to encapsulate these extension components into plug-ins.The idea is to develop all the needed extension components inside the plug-ins, and load them into the middleware by loading the plug-ins.
Plug-in platforms represent a flexible approach for building software systems which are extensible and customizable to the particular needs of the individual user [18].Plug-in platforms enable the extension of a core application with new features implemented as components that are plugged into the core at load-time or even at run-time and integrate seamlessly with it.The best known use of plug-in technology is in web browsers and the Eclipse platform 8 .In addition, the popular Unik-olsrd 9implementation of OLSR supports a plug-in framework based on encapsulating the plug-ins in dynamic libraries.The core application uses a plug-in by following a service interface.A plug-in is an already compiled application piece that provides a certain, usually very specific, function or service "on demand".The plug-ins depend on the mechanisms provided by the core application and do not usually work by themselves.
Separating the implementation of the extension components and encapsulating them using plug-ins greatly facilitates the sharing of these components created by third party middleware users (or a separate team in the project); thus accelerating the development of new adaptation solutions by reusing extension components.Another benefit is for a plug-in developer to avoid the interaction with the middleware source code when developing the plug-in, even avoiding compiling the whole middleware.Experience tells us that learning to extend and compile an already developed system (possibly of thousands of lines of code and files) is not trivial and is time consuming, hence this can greatly increase the development time.
The architecture defines four different types of plug-ins, each with their own service interface to offer the middleware the different extension components.In addition, each of these different plug-in types share a common set of methods giving meta-information about the plug-in that will serve to identify it, such as version, authors name, name of plug-in, type, etc.The four types of plug-ins and their relationship with the extension elements are shown in Fig. 4, these are: • The application plug-in, offering only one application component.The application plug-in can also offer multiple context elements to the context environment, since an application is a context source.• The contextE plug-in, which offers multiple context elements components.The aim of y this type of plug-in is to offer contexts elements from the node or vehicle, not tied to a NL protocol or application.For example a contextE plug-in wrapping around a GPS receiver offering time, speed, location information; another example could be a contextE plug-in offering context elements related to some sensor of the vehicle.We finish describing the plug-in aspect of the architecture by showing the plug-in interfaces (API) used to construct the plug-ins and offer the extension components to the middleware.The plug-in API consist of four interfaces for the four types of plug-ins in the middleware, plus the IPlugin interface.The IPlugin interface contains the set of methods to provide meta-information about the plug-in, this interface must be implemented by every type of plug-in, or in object oriented perspective, the other plug-ins interfaces extend from the IPlugin interface (see Fig. 5).
Finally, we present the definition of all the different plug-in

E. Identification mechanism of extension components
As we explained in a previous section, the extension components of the architecture are created independently of the middleware.The architecture needs a method to uniquely identify each extension component and refer to them at load-time and run-time, even between those from the same type.In this section we describe how we address this issue.
We defined two ways to uniquely identify an extension component depending on a one-to-one or one-to-many relationship between the plug-in and the extension component.For the extension components having a one-to-one relationship with the plug-in (NL protocol, the application, the adaptation algorithm), these extension components are uniquely identified from all the other by taking into account the duple (NP , HP ), where: • NP is name of the plug-in containing the extension component and also the name of the extension component.• HP is the hash value of the plug-in containing the extension component.
For extension components having a one-to-many relationship between the plug-ins, like the context elements and the adaptation actions, these extension components are uniquely identified from all the others by taking into account the tuple (NP , HP , NE ), where: • NP is the name of the plug-in containing the extension components.
• HP is the hash value of the plug-in containing the extension component.• NE is the name of the extension component.We assume that this value is unique across the other extension components contained in the same plug-in.
To store and represent the identification information of the extension components, we proposed the use of the ElementIdentifier class shown in Fig. 6 a).ElementIdentifier is simply a container class with three data fields that will contain the identity information needed by the different types of extension components of the architecture.The use and meaning of these three data fields are shown in Fig. 6 b).

F. The adaptation configuration
After all the needed extension components are loaded in the middleware, the next step is to build the adaptation solution by expressing their relationship.The mechanism to describe an adaptation is by declaring an adaptation configuration (see Fig. 7); here we state the associated ElementIdentifier references of the adaptation algorithm we want to use, what context elements are needed as input, the adaptation actions associated to the output values.In addition we state the adaptation mode where this adaptation solution will be executed, and assign a name for the configuration.An adaptation configuration also contains other additional fields that are adaptation mode specific, these are: • Protocol and application fields: These fields are needed by an adaptation configuration in the send, receive and forward adaptation modes.Its purpose is to tie a configuration to a network operation between a specific application and protocol; i.e. a send configuration associated when application X calls the send command to NL protocol Y .The architecture allows the middleware user to create any number of adaptation configurations thus enabling the definition of multiple adaptation solutions in an adaptive Network layer.

G. Middleware aspect of the architecture
The PLUGAM architecture is conceived as a middleware system, situated between the Application and Network layers because the interception of messages between the applications and NL protocols is needed to enable the Send, Receive and Forward adaptation modes.The middleware aspect also serves to help manage the multiple NL protocols and multiple applications aspect of the architecture.There is no direct communication between applications and the NL protocols instead they communicate indirectly using the services offered by the middleware.In reference to the role of a possible Transport layer in the architecture, the services of this layer will need to be embedded in either the NL protocol or the application.Fig. 8 shows the position of the middleware from the point of view of the OSI layers.The multiple NL protocol aspect of the middleware architecture facilitates the use of use different communication channels (WIFI, 802.11p, 3G, GSM, etc.) in the system.This can be achieved by encapsulating each communication channel lower level protocols (Physical and Link layer) plus the NL protocol in a protocol plug-in.If two NL protocols in the middleware share the same communication channel (e.g. one for unicast communication and another for dissemination each sharing the 802.11p radio), possible inter-protocol interference must be dealt with by the middleware user.Furthermore, having too many protocols is not desirable, because they are complex modules and may quickly bloat the middleware; finding an optimum set of NL protocols that service all the applications communications needs is out of the scope of this work.

H. Special adaptation actions of the architecture
As we mentioned in the adaptation model, the NL protocols offer different adaptation actions to allow the modification of its behavior.In addition, this definition gets extended to account for special adaptation actions, we called them special because they are offered by the middleware and not the NL protocols.The special adaptation actions are used to allow adaptations where the result is a change of behavior between NL protocols and applications.Based on the foregoing and exploring some possible modifications in the interactions between NL protocols and applications, we extend the definition of adaptation actions to conceive three types of adaptation actions in the architecture: • Protocol adaptation actions • Special switcher adaptation action • Special filter adaptation action The protocol adaptation actions are offered by NL protocols and their purpose is to change the behavior of the protocol by linking it to a protocol internal variable or parameter.A NL protocol can have multiple adaptation actions, each linking to an internal variable.For example a dissemination NL protocol can offer an adaptation action linked to extending or lowering the dissemination spread via changing the value of an internal variable of the protocol, or an adaptation action linking to the HELLO interval constant of the OLSR NL protocol.
The purpose of the special switcher adaptation action is to redirect a message from the predefined path between NL protocols and applications; this adaptation action is used for doing a change between NL protocols adaptation.The switcher receives as input an ElementIdentifier object with the reference to the protocol or application to redirect the message to.The actual decision of where to redirect the message is done in the adaptation algorithm, then by linking to one of the adaptation algorithm outputs the switcher receives the final decision and redirects the message.If the switcher is included in an adaptation solution located in the send and forward adaptation modes, the switcher redirects between the available NL protocols that the application registered at the initiation step.If the switcher is included in an adaptation solution located in the receive adaptation mode, the switcher redirects between the applications having registered the NL protocol where the message comes from.Fig. 9 a) shows an example of how the switcher works.In this example the adaptation solution having the switcher is located in the send adaptation mode, and the default path of the message was to go the NL protocol #1, but the ElementIdentifier reference received as input told the switcher to redirect the message to NL protocol #2.
The purpose of the special filter adaptation action is to recreate a pass or not to pass behavior.This adaptation action can only be used in the send, receive and forward adaptation modes.The filter receives as input a boolean data type where a value of true means that the filter lets the message pass to the destination protocol or application, with a value of false the message is dropped.In Fig. 9 b) shows an example of how the filter works, in this example the adaptation solution having the filter receives the value of false, the filter then drops the message and it does not go to the NL protocol #1.
To finalize the description of the adaptation actions, the architecture introduces the AdaptationActionValue class to represent the value of an adaptation action at run-time similar to the context element value concept.An adaptation action value can also be of any data type similar to a context element value, which is why the definition of the Adaptation-ActionValue class contains exactly the same attributes as the ContextElementValue class.

I. Interaction of applications in the adaptation middleware
In this section we describe how a vehicular application interacts with the middleware and associates to the NL protocols that it will use during its execution.Foremost, the middleware has control of the lifetime of the applications.Applications are started by the middleware and stopped when the middleware terminates.
Furthermore, an application will not interact directly with the NL protocols, instead it uses the middleware as a proxy.Two-way communication between applications and middleware is achieved using two interfaces: the IApplicationPlugin and the IMiddlewareProxy.The middleware communicates to the application by calling methods of the IApplicationPlugin interface (define in the appendix in Fig. 22).An application communicates with the middleware by calling methods in the IProxyMiddleware object, the definition of the IProxyMiddleware interface is shown in Fig. 10.
When the middleware registers the available applications, the middleware creates a middleware proxy object tied to each registered application, then the middleware passes this object to the respective application using the SetMiddlewareProxy method of the IAppllicationPlugin interface.Moreover, at the application's registration step the middleware queries the application via the GetAppDeclaredProtocol method of the IApplicationPlugin interface, this method returns a list of references (ElementIdentifier objects) of all the NL protocols that the application needs.The middleware must search if these NL protocols where indeed loaded in a prior step.After the application starts, it must use the proxy middleware object to interact with the requested NL protocols.In Fig. 11 we show the sequence diagram of the steps done by the middleware to register an application, here is where the middleware registers the requested NL protocols of the application and passes the middleware proxy object to it.At run-time, when an application wants to send a message to a NL protocol, it must call the send method of its middleware proxy object.This send method receives as input an ElementIdentifier object with a reference to the NL protocol chosen to send the message, in addition to an AdaptationMiddlewareMessage object wrapping the contents (an array of bytes) of the message to send; the definition of the AdaptationMiddlewareMessage class is shown in Fig. 10.Moreover, the middleware calls the onReceiveMessage method of the IApplicationPlugin to transfer a message receive from a NL protocol to the application.
The dstAddress field in the AdaptationMiddlewareMessage object must be filled by the application before sending the message, in order to instruct the NL protocol the destination node of the message.In this version of the architecture, we do not address the issue of having different representations of a Network layer address depending upon the different types of NL protocols; for instance, for a dissemination or geocast protocol the destination address could be difficult to be represented by an IP address.We will leave this issue as future work and for now assume that using an IP address will suffice.
The appIdent and protoIdent fields of the AdaptationMid-dlewareMessage contain the references of the application and NL protocol that originally sent the message.These fields are assigned by the middleware after the application calls the send method in the middleware proxy, the application can view this information when it receives the message.The appIdent field is specially useful for when the middleware redirects the message to the right application, this is analogous to the TCP port of the TCP/IP stack.Finally, the scrAddress field of the AdaptationMiddlewareMessage is assigned by the NL protocol when sending the message, when receiving a message this field can be consulted by the application.

IV. DESCRIPTION OF CASE STUDY EXAMPLES
In this section we present two simple case studies of adaptive protocols built with our adaptation middleware architecture, each presenting two distinct domains of the middleware behavior.These case studies will help us better explain how all the aspects of the architecture work together in order to build an adaptive Network layer and also as a proof of concept of the architecture.The first case study is about extending an existing MANET NL protocol to be more dynamic by adapting it based on local context, thus making it better suited to be used in VANETs.In the second case study we propose to implement a conceptual scenario with our architecture, where a selection or switch must be made between two NL protocols.Below we present a description of these case studies and how they are implemented with our architecture.

A. Case study 1: Modifying an existing NL protocol to make it more dynamic by adapting to local context
As we previously mentioned, this case study extends an already defined NL protocol by adding the functionality of adapting to certain context information.As the base NL protocol for the case study, we chose one from MANET because there are still no reference protocols for VANET.We selected OSLR because it is particularly well-known, with a lot of work around it and with code availability.OLSR 10 is a proactive protocol which maintains an up-to-date routing table using periodic messages (e.g.hello messages) received from neighbors.Huag et al. [19] experimented with the HELLO INTERVAL constant which is the time period to send these hello messages and it is strongly related to the up-to-dateness of the routing table.They tested performance changing this constant using different scenarios of node density and node mobility.They concluded that adjusting this constant can bring improvements in performance and proposed as future work to adapt it dynamically at run-time.We used Huag et al. results and future work as the basis for the adaptation proposal of this case study, this way we have a certainty that the impact of the proposed adaptation will be indeed beneficial.
Associating the case study 1 with the concepts of our architecture for adaptation, the HELLO INTERVAL constant is represented as an adaptation action offered by a protocol plug-in implementing OLSR.The context information which will be the input of this adaptation will be a simplification of the node mobility, the node or vehicle speed.There are more complex and precise ways to represent the node mobility (e.g. in [11] the mobility metric is based on link duration of the neighbor nodes), nonetheless to simplify the description of this case study example we think that using the vehicle speed serves the purpose.We proposed to obtain the vehicle speed by creating a ContextE plug-in wrapping a GPS code which calculates this information by measuring the Doppler shift in the signals from the GPS satellites, this ContextE plug-in will offer the middleware the context element of "vehicle speed". 10http://tools.ietf.org/html/rfc3626 In addition, we need to describe the adaptation algorithm that we will use for the case study 1 adaptation solution.We decided to create an extremely simple adaptation algorithm based on one-on-one mapping between the vehicle speed and the HELLO INTERVAL value.The adopted vehicle speed and HELLO INTERVAL relationship is based on the following simple reasoning: at higher vehicle speed the neighbors change more rapidly, hence the neighbor table must be updated more often by lowering the value of the HELLO INTERVAL.This reasoning does not take into account the existence of neighbor nodes driving at high speed alongside the vehicle, however for this example it is useful enough.To implement the one-on-one mapping, we defined the pairs  With the help of the (v i , f (v i )) pairs, we can compute the HELLO INTERVAL f (v), where v ∈ ℜ, as follows: Finally, the adaptation solution for case study 1 will be located in the CUPIB adaptation mode.This mode will periodically re-execute the adaptation solution thus updating the HELLO INTERVAL value; we are defining the CUPIB period (in the CUPIBTime field of the adaptation configuration) to 1000 ms because is the update rate of a common GPS device.
We now proceed to explain how to build the case study 1 in our architecture.The first step is to construct the following plug-ins (see Fig. 12): • Create a protocol plug-in of OLSR, this plug-in will offer an adaptation action tied to the HELLO INTERVAL constant of OLSR.Once we have all the required extension components, a second step is to link them all by declaring an adaptation configuration as shown in Fig 13; the configuration shown here is in JSON format as we implemented it in the proof of concept prototype.Looking at this JSON code we can see that most of the elements constituing an adaptation configuration are in the form ElementIdentifier objects represented in JSON as the {"name":, "hash":, "secondname":}.In addition, this adaptation configuration is declared in the CUPIB adaptation mode and the CUPIB time field is to 1000 ms.

Fig. 13. Adaptation configuration of case study 1 in JSON format
That is all there is to create the adaptation of case study 1 in the adaptation middleware, at run-time the middleware will execute this adaptation solution periodically due to how the CUPIB mode works, hence changing the HELLO INTERVAL constant of OLSR depending of the node speed.

B. Case study 2 : Adaptation based on switching between different NL protocols
In this case study we present an adaptation in which a selection or switch between different NL protocols must be made depending on the current context.To achieve this we describe a simple scenario where such switch between NL protocols is needed.This scenario is the dissemination of an accident event in the road to interested vehicles.We chose to use a directional broadcast NL protocol to only inform vehicles driving in the same direction as the vehicle which had the accident.This works well when there are enough vehicles driving in the same direction (scenario A in Fig. 14).However if there are not enough vehicles driving in the same direction to relay the message, the communication of the message fails.We propose to exploit the vehicles driving in the opposite direction, and switch to use a carry and forward protocol given this context (scenario B in Fig. 14).The conditions to switch or select the NL protocol are: if there are not neighbors in same direction and we detect a vehicle passing in the opposite direction.If these conditions are meet then switch and use carry and forward protocol, if not continue using the directional broadcast.
For this scenario we could choose to put the adaptation solution in two adaptation modes: send or forward.Depending of the chosen adaptation mode the behavior is different.If we choose to insert this adaptation solution at the send adaption mode, then the switch between protocol can only happen in the source node, specifically when the application calls the send command to a NL protocol throughout the middleware.If we want to execute the adaptation solution at each hop, we must insert the adaptation solution in the forward adaptation mode.Is it possible to put the same adaptation solution in both the send and forward modes by creating two different adaptation configurations.In Fig. 14 we opted to use the send adaptation mode for demonstration purposes.
Having described the case study 2 scenario we proceed to show how to build it in our architecture.Foremost is to construct the necessary plug-ins to provide the extension components needed for this adaptation configuration, which is why we constructed the following plug-ins (see Fig. 15): • Two protocol plug-ins, one implementing the directional broadcast protocol, and another for the carry and forward protocol.To implement the context elements needed for this adaptation solution, for this example we decided that the carry and forward protocol will provide them.These context elements are very simple Boolean values indicating if there is a neighbor passing by in the opposite direction or not, and if there are neighbor vehicles driving in the same direction or not.Nevertheless, computing the value of these context element is not trivial, the implementation of how to compute them is up to the protocol implementation and not shown in this example.• We need an application plug-in with the accident in the road application, this application requires the directional dissemination and the carry and forward NL protocol to work, hence their ElementeIdentifier objects must be included in the list returned by the GetAppDeclaredProtocols method of the IApplicationPlugin interface.• Finally we need an adaptation algorithm plug-in containing the logic of how to select the protocol to switch.The output type of this adaptation algorithm must match the parameter type of the special adaptation action switcher, which is an ElementIdentifier data type that refers to a NL protocol.The algorithm contains a very simple conditional operation using the two Boolean context elements.Next, we need to link the functionality of the extension components by declaring the adaptation configuration, Fig. 16 shows the adaptation configuration of case study 2 expressed again in JSON format.An important remark about an adaptation configuration created for the send adaptation mode, is that the application and protocol fields must also be assigned in order for the adaptation to be executed only when the hazardous situation application sends a message to the directional broadcast protocol (which is the default NL protocol for this scenario).

Fig. 16. Adaptation configuration of case study 2 in JSON format
Once the middleware loads the adaptation configuration, it will execute this adaptation at run-time.To finish the description of this case study example we will present how this adaptation is performed inside the middleware at run-time (see Fig. 17).It all starts when the hazardous situation application calls the send command to disseminate the message using a directional broadcast protocol (1).Instead of going directly to the protocol, it is intercepted by the middleware and goes to the send mode module.Here a lookup is performed to see if there is a configuration defined at initiation for the application-protocol pair (2), which indeed there is and it's named "Adaptive example #SW".Next is the execution of the adaptation solution declared in the configuration (3); first the middleware gets the current context element values from the context environment via the context manager (3.a), then these values are passed as inputs to the adaptation algorithm which executes and produces the output value needed to the adaptation action, in this case the special adaptation action switcher.The middleware then transfers the value to the switcher module which does the actual redirection of the message to the chosen NL protocol (4).In the run-time example of Fig. 17 the context elements are such that the message is directed to the carry and forward protocol.

V. DESCRIPTION OF PROOF OF CONCEPT PROTOTYPE
As proof of concept we decided to implement a prototype of the PLUGAM adaptation middleware.An important aspect for the prototype was to find a proper plug-in platform.In addition, working on an implementation of the PLUGAM architecture helped us better define some lower level details of the architecture and have a more solid proposal.In this section we present the implementation details of this prototype.
In regard to the search for a plug-in platform, we found some plug-in frameworks, platforms in Java and C#, and HTML programming languages.For example the Chrome extension framework 11 allows the creation of extensions (plug-ins) developed in HTML and packed inside a zip file containing the HTML code and a manifest in JSON format to store the extension's meta-data.In the case of more traditional programming languages like C# and Java, the binary code of the plug-in can be packed as a DLL file in C# .NET [18] and as a JAR file in Java.To identify that a binary file is a plug-in instance and to manage plug-in meta-data, .NET attributes and reflection services can embed meta-data directly in the DLL file; Java relies on reading meta-information defined in a manifest text file inside the JAR file.
We selected OSGi and iPOJO as the base technologies for the plug-in platform.We chose the OSGi platform 12 which is developed using the Java programming language.OSGi defines an architecture for modular application development, these modules are JAR files which in OSGi are named bundles.A plug-in from our architecture is a bundle that offer services available in the OSGi environment, and the adaptation middleware will be another bundle accessing the plug-ins services.The main reason to select OSGi as the plug-in platform is because the OSGi is a solid platform; also its community is currently very active, there is a lot of development to improve and extend the platform and there are a lot of additional tools to deal with bundles.
The other technology constituting the plug-in platform is iPOJO 13 , its purpose is to simplify OSGi application development and promotes service-oriented programming on OSGi platforms.Based on the concept of POJO (Plain Old Java Object), application logic is developed easily.A PLUGAM plug-in will be implemented as an iPOJO service.Thanks to iPOJO there is no need to make reference or calls to OSGi code to be able to implement an application module via OSGi, the linking of OSGi and the iPOJO component service to the application logic is made at the compilation level.In other words, the use of iPOJO reduces the development of a plug-in in the prototype to simply writing a normal plain Java class that implements a Java interface, this interface being one of the PLUGAM plug-in interfaces.
The OSGi platform specification has many different open source implementations commonly known as OSGi containers; for example Equinox OSGi, Apache Felix and Knopflerfish OSGi.In our case we selected Apache Felix 14 as the OSGi container because its development and community is very active and it is used as a base for industry quality architectures like ServiceMix 15 .
We implemented the adaptation middleware as an OSGi bundle that will be running in the same OSGi container as PLUGAM plug-ins.When the middleware bundle is started by the user it will detect all the plug-ins which are already loaded in the OSGi container.In addition to developing the plug-in platform of the prototype, we implemented some test plug-ins.Specifically we implemented the necessary plug-ins 13 iPOJO webpage: http://felix.apache.org/site/apache-felix-ipojo.html 14 Apache Felix webpage: http://felix.apache.org/site/index.html 15Apache ServiceMix is an open source Enterprise Service Bus: http://servicemix.apache.org/home.htmlto implement the case study 1 example in the prototype: • A OLSR protocol plug-in which is developed using the OLSR code found inside the Mchannel16 middleware implementation.This plug-in offers an adaptation action to modify the HELLO INTERVAL of OLSR.• A contextE plug-in offering GPS context information by connecting to a Bluetooth GPS; we modified the base code of the GPSylon project 17 to create the plug-in.This plug-in offers two node speed context elements, one obtained from GPS NMEA readings and the other one calculated from two positions, it also offers longitude, latitude, time, number of satellites caught by the GPS.• An adaptation algorithm plug-in of the simple vehicle speed to HELLO INTERVAL mapping we talked about in section IV-A.
Thanks to the use of iPOJO creating a plug-in for the prototype is rather simple and involves doing the following steps using the Eclipse development tool: • Create a new Java project in Eclipse, then import the PluginServices.jar in your project; this jar is also a OSGi bundle which contains all the auxiliary classes and the plug-in interfaces for the middleware and plug-ins to interact with each other.• Create a class in the project and make it implement one of the plug-in interfaces.• Compile the project into an iPOJO bundle using Apache Ant and the input files build.xml,metadata.xmland <Project name>.bnd,these files must be customized for each plug-in project.• Put the resulted bundle in the plug-ins folder of Apache Felix.
Installing the prototype is also simple thanks to Java and Apache Felix, involving only to copy the contents of the Apache Felix folder with the bundles of the adaptation middleware to the computer, then put the self-created plug-ins in the pre-defined folder of Apache Felix.To run the middleware prototype, we must start the Apache Felix JAR file (as shown in (1) of Fig. 18), wait a few seconds until Apache Felix detects the installed plug-ins, then in the command console of Apache Felix start the bundle of the PLUGAM adaptation middleware (as shown in (3) of Fig. 18).

VI. PLUGAM EVALUATION
The evaluation of the adaptation middleware is presented in two phases.First a cost/performance evaluation, which is based on a set of measurements to the prototype in order to get a rough idea on the cost of using the middleware in the vehicular system.The objective of these measurements is to determine if such middleware architecture is viable to implement in a future vehicular system.Moreover, in addition to presenting two case studies examples as proof of concept of the proposed architecture, in the second phase of the evaluation we go further and perform a set of experiments/simulations to analyze the impact of one of these specific adaptations, the case study 1 example, in order to confirm if in practice this adaptation solution indeed brings performance gains as proposed in theory by Huag et al. [19].Finally, we discuss the scalability of the proposed architecture and talk about the additional costs introduced by our generic approach in contrast with an existing adaptive protocol, which is a particular solution.

A. Performance/cost measurements
To evaluate the performance or cost of the adaptation middleware we designed a set of measurements to be done to the prototype.The aim of these measurements is to analyze the possible processing and memory cost of using a plug-in platform, and the processing cost added by the middleware between the interactions of the applications and NL protocols.The objective of this evaluation is to determine if such middleware architecture is viable to implement in a future vehicular system.
For the performance/cost evaluation we made measurements to the following aspects of the prototype: • Memory requirements of the prototype.
• Processing costs or additional latency generated by the adaptation middleware when executing adaptation solutions in all the adaptation modes.• Finally we are interested in analyzing the memory and processing overhead introduced by the prototype's plugin platform.
All the measurements performed to the prototype where made on a MacBook Air model A1231 ( 2008), which contains an Intel Core Duo 1.6GHz and 2Gb of RAM.On the software side, we used the Ubuntu 10.10 operating system, the installed software is Java JRE 1.6.0.22,Apache Felix version 4.0.2 and iPOJO 1.8.2.We believe that these hardware and software specifications will be similar to the on-board systems of two-three years future vehicles, with a price point of $700-1100 USD, using computer tecnology from four or five years behind and most probably using a version of Linux or Windows Embedded.For example the MyFord Touch costs around $1150 USD an uses Microsofts Windows Embedded Auto software platform, has an ARM Cortex A8 600 MHz CPU with 512 MB RAM, 2 GB NAND flash memory.The Toyota Entune costs around $1050 USD 18 .On another aspect all the measurements of the prototype were done a hundred times and we are showing the average value and confidence intervals.

1) Prototype memory requirement:
Due to the possibility and interest of deploying these vehicular systems in embedded systems or even smart phones, which have limited processing power and specially memory limitations, it is of interest to have an idea of the memory costs of using the adaptation middleware, more specifically the ROM and RAM usage.The general memory requirements obtained from the prototype are: 20.1 MB of RAM and 111.9 MB ROM memory (size for PLUGAM binary files).
The above RAM value was obtained from the memory footprint of the java process reported by the process status (ps) program in Linux.A deeper examination of the 20MB RAM usage of the prototype reveals that 16.17 MB are needed to run the plug-in platform environment (iPOJO + Apache Felix + JVM), the JVM alone consumes 6.72 MB.On the other hand, from the above ROM value, 109.5 MB correspond to the JVM files, only 1.98 MB correspond to the Apache Felix with iPOJO files, and the last 442 KB correspond to the adaptation middleware files.Moreover, if we include the plug-ins needed to implement the case study 1 example in the prototype, the ROM increases an additional 4.03 MB.
Furthermore, an important memory overhead of the adaptation middleware is the addition of a middleware specific header to the messages generated by the applications.This header contains the information of the AdaptationMiddlewareMessage object (shown in Fig. 10).Since the fields of the AdaptationMiddlewareMessage has ElementIndentifier objects which contains strings, the size of the header depends on the maximum number of characters for these strings.By setting this maximum size to 30 characters of one byte each, and using a IPv4 Address representation of 4 bytes, resulted in a header size of 132 bytes.
In summary, the resulting ROM and RAM requirements are modest and should fit even on today's low cost Android smartphones, which generally have 512 MB of ROM and RAM; we highlight Android devices because Apache Felix can be configured to run on Android systems thus making feasible to run the adaptation middleware in them.The plug-in platform implementation using Apache Felix is the source of most of the RAM usage of the PLUGAM prototype.The JVM is responsible for most of the ROM usage of the prototype.Finally, the resulting header's size is high and could be reduced by redefining the ElementIdentifier class, preferentially by omitting the use of strings in the identification mechanism of the architecture.

2) Prototype processing overhead:
The goal of obtaining these measurements is to have an approximation about the processing cost (latency) induced by using the adaptation middleware.In the send, receive and forward adaptation modes, the middleware intercepts the passing of the messages between the vehicular applications and the NL protocols and executes an adaptation solution in between.In the case of the CUPIB mode, the recalculation of the variables inside the NL protocols also depends on how much time the adaptation solution is executed in this mode.We are interested in knowing the processing time of executing an adaptation solution with the different variations of adaptation modes, with the special adaptation actions, and with different types of adaptation algorithms.
Because the instructions and operations inside an adaptation algorithm are defined by the plug-in developer, inside there could be any number of instructions and complex operations.For the purpose of obtaining measurements with different types of adaptation algorithms, we defined four profiles of an adaptation algorithm, we named them "algorithm load" and they are based on quantity of operations with floating point numbers, the devised algorithms loads are: • None: An adaptation algorithm without any instructions or operations.• Low: Represented by an O(n) algorithm and implemented by an average estimation algorithm of a list of n real numbers.This load is intended to represent an algorithm that contains some variable assignments, comparisons and mathematical operations with the input context elements.• Medium: Represented by an O(n 2 ) algorithm and implemented by a selection sort algorithm which sorts a list of n real numbers.This load is intended to represent adaptation algorithms that do more sophisticated operations to the context elements.• High: Represented by an O(log(n)n 2 ) algorithm and implemented by a selection sort algorithm done Log(n) times.An algorithm with load of HIGH is very bulky and does high and complex number of operations, represents an extreme case.
In addition, to associate the algorithm load concept with the number of context elements which are the inputs of the adaptation algorithm (NUM CONTEXTE), as well as with the number of adaption actions output to the algorithm (NUM AACTIONS), we defined n as indicated in Eq. 2, where m = 100 represents a base size of a list containing floating point numbers.
The execution times of these different adaptation configurations are shown in Fig. 19, each measurement is the average of running it 100 times and includes the confidence interval of 95%.The charts a) and b) show the processing times measurements of the send, forward and receive adaptation modes.In a) by fixing the number of context elements to 5, then varying the load of the adaptation algorithm.In b) by fixing the algorithm load to NONE, then varying the number of context elements used as input to the adaptation algorithm.The SF, SS, RF, RS, FF and FS abbreviations in the horizontal axis of a) and b) refer to a combination of the adaptation mode and the special adaptation action used in the adaptation configuration; the first letter refers to the adaptation mode where the configuration is executed (Send, Receive, Forward), and the second letter refers to the special adaptation action we put in the configuration as output to the adaptation algorithm (Filter, Switcher).Examining the results of the processing cost measurements of the adaptation middleware, we concluded the following:

The charts c) and d) of
• The send and receive modes have very similar processing times, this is due to their similar implementations in the prototype.The forward mode processing times are a little higher than the send and receive modes, approximately 0.04 ms more.• The processing measurements in all the adaptation modes shown in the charts are located between 0.1 to 0.6 ms.The highest processing time obtained in the measurements was 1.6 ms of in CUPIB adaptation mode, with an algorithm load in HIGH, 9 context elements as input and 9 adaptation actions as output; this measurement does not appear in the charts of Fig. 19.• The algorithm load HIGH greatly elevates the processing times several tenths of a millisecond.• The processing time of all the adaptation modes when increasing the number of input context elements in the algorithm only increments a few hundredths of milliseconds per context element.• In the CUPIB mode, the processing time increments are more steep in relation with the number adaptation actions as output that when we add more context elements in the input of the adaptation algorithm.
Additionally, using the previous measurements framework we estimate the processing cost for the case study 1 example, which uses one context element as input, one adaptation action as output, and an algorithm load of LOW because the algorithm is a simple mapping of speed to hello interval values.The processing time for case study 1 example resulted in 0.191 ms, this latency was introduced in the simulation of case study 1 in Section VI-B.
The measured time to initiate the middleware resulted in 654 ms.The initiation step covers from when the adaptation middleware bundle is started in Apace Felix to when the NL protocols, applications and adaptation solutions in all the adaptation modes are started by the middleware.
Finally, based on the processing delay measurements of the adaptation modes (presented in Fig. 19), we described the end-to-end delay incurred by the PLUGAM middleware.For each adaptation mode the end-to-end delay is affected in the following way: • In case of executing an adaptation solution in the CUPIB mode, the end-to-end delay of a message is not affected because the execution of CUPIB is concurrent to the NL protocols, vehicular applications and message passing between them.• In all the end-to-end path of a message, the send mode only adds a processing delay in the source node.• As for the receive mode, through all the end-to-end path of a message, this mode only adds a processing delay in the destination node.• In forward mode the adaptation solution is executed in each node of the end-to-end path which relays the message, hence the processing delay of the forward mode must be multiplied by the number of relay nodes of the path, in order to get the end-to-end delay of the middleware.
Fig. 3 of Section III-C is useful to understand the end-toend delay of the send, receive and forward modes, because it shows their location in the end-to-end path of a message.
We present an analytical estimation of the end-to-end delay overhead of the middleware for two common types of NL protocols: unicast and dissemination.We assume that only one adaptation solution is defined either in the send, receive or forward adaptation modes.These estimations are shown in Table II.For the unicast estimation we assume that the end-to-end route of the message consists of R nodes.For the dissemination protocol estimation, we defined RN as the number of nodes participating in the retransmission of the message (this number depends on the specific dissemination protocol), and DN as the number of destination nodes that transfer the message to the vehicular application.
In addition, SC refers to the processing cost of the search operation for an active adaptation configuration in the adaptation mode.This processing cost must be made even if no configurations are defined in the adaptation mode by the user.CS stands for the processing cost of executing an adaptation configuration defined in the send mode, CR in the receive mode, and CF in the forward mode.3) Plug-in platform memory and processing overhead: A major aspect to consider about our proposed middleware architecture, is the impact and feasibility of introducing a plug-in platform to a software system such as a middleware for vehicular systems, being that the plug-in platforms found in the software community are complex systems by themselves.We are particularly interested to see if adding a plug-in platform to communicate the internal middleware components does not add enough latency to the process.
In this particular plug-in platform implementation based on OSGi and iPOJO, in addition to the code written by the developer to implement a plug-in interface, in the compilation step extra code is automatically injected to the CLASS files in order to support the plug-in platform.This obviously increases the size of the plug-in binary (the JAR file) created by the developer.To measure this aspect we took the ROM measurements from five plug-ins developed for the implementation of the case study 1 in the prototype, then we compiled them without OSGi and iPOJO functionality, only with OSGi functionality (making it an OSGi bundle), and with OSGi and iPOJO functionality.From these measurements we found that the OSGi overhead code is small, in average only adding 345 Bytes to the plug-in binary, this small value is due to the fact that creating an OSGi bundle involves only adding some OSGi meta-information to the manifest file inside the JAR file.
In regard to the iPOJO code overhead, we found that it adds an average of 3.5 KB of code to the plug-in binary.Moreover it increases the size of the class file implementing the iPOJO service by 86.84%, this code overhead originates because adding iPOJO functionality involves an injection of iPOJO specific methods to the original CLASS file; this code injection is done automatically by the Apache Ant compiler.
As we mentioned in previous sections, the plug-in platform communicates the extension components (added NL protocols, applications, etc.) to the middleware, this communication using the plug-in platform adds a processing overhead or extra latency that we think is interesting to measure.To calculate this latency we recreated a scenario in which we have two iPOJO components A and B, where A uses the B component and both components are located in different bundles or JAR files.Then at run-time we measured the time between when component A calls the method of component B and until it immediately enters the method of component B. The resulted latency was 0.009 ms, which is a very small latency.However we noticed a bigger latency (1.74 ms) when an iPOJO method is called for the first time, this behavior occurs because at run-time iPOJO delays loading the iPOJO components until the component methods are actually called by another, and not at initiation time (iPOJO calls this "lazy object creation").Finally we measured the initiation time of the prototype's plug-in platform, we measured the time since the Apache Felix OSGi container is started by calling the "java -jar felix.jar"command until when Apache Felix loads the PLUGAM plug-ins and gives execution control to the adaptation middleware.The measured time was of 2.4 seconds, from which 0.986 ms are needed by Apache Felix to start the OSGi container and the rest is spent on loading the plug-ins from a specific folder of Apache Felix.
In summary, the code required to encapsulate the extension component functionality into a plug-in is small, a few KB, and most of this extra code comes from iPOJO.In contrast, the extra code required to create an OSGi bundle is minimum.Moreover, this plug-in platform implementation is very light and adds very little latency when communicating the plug-ins with the middleware, however the first time these two modules communicate generates a significant latency.Furthermore, the 2.4s initiation time of this plug-in platform implementation is lengthy, which in addition to the middleware's initiation time of the ( pressented in Section VI-A2) sums up a total of approximately 3 seconds of initiation time before the NL protocols and applications start working.This start-up delay must be taken into account when deploying the vehicular system in the target vehicles.

B. Evaluation of case study 1
In this section we present an evaluation of the adaptive protocol proposed for the case study 1 example throughout simulation.The idea of this evaluation is to show a brief quantitative evaluation on the impact of specific proposed adaptation, which is built with our middleware.We want to assess if even this simplistic adaptation proposal indeed generates a performance increase as reported by Huag et al. [19].
Moving on to the details of this evaluation, essentially we compared two protocols, the default OLSR protocol and the adaptive OLSR protocol which includes the adaptation proposed for case study 1.Both are based on UM-OLSRv0.8.8 19an OLSR implementation for NS-2.We measured the following metrics in the simulation to compare the performance of the two protocols: • Average goodput of all data connections in the simulation, the goodput is defined as the amount of useful data delivered (in bytes) divided by the data connection transfer time.
• Normalized routing overhead (NRO), which is defined as the ratio between the number of control packets propagated by every node in the network, and the number of data packets received by the destination nodes.This metric is strongly related to the control packet overhead of the NL protocol.
We also measured the average end-to-end delay, however the resulted delay values were too scattered thus not useful when comparing the two protocols, this can be explained because the OLSR protocol itself is not sensitive to delay.
For the NS-2 simulation, the speed context element for each node is obtained from the speed value in the MobileNode class in the NS-2 code; this speed value has 100% precision contrary to the speed values obtained from a real world GPS.Moreover, instead of porting the entire middleware to NS-2, we only added the CUPIB mode functionality to the adaptive OLSR protocol, more specifically we added a delay of 0.1916 ms obtained from the cost evaluation of the prototype, in order to emulate the processing overhead of the adaptation middleware when executing the CUPIB mode.
In addition, to simulate a city scenario we used real data (roads specification) concerning a urban area of the city of Ensenada in Mexico, this data was exported from openstreetmap 20 (see Fig. 20).For the simulation of vehicles and their movements (considering traffic lights) we used the SUMO tool 21 .We generated the flow of vehicles from 41 routes in the map by defining the begin and end points of the routes.The internal vertices of routes were generated automatically by the SUMO duarouter program that uses Dijkstra's shortest route algorithm, where the edge weights are a combination of the max speed of a street, the distance to the destination and also from traffic situation.To emulate real world vehicle movements, the vehicles can enter and get out of the simulation area.The city max speed and hence the vehicles max speed was set to 40 kph.The wireless range was set to 150 m, instead of the default 250 m of 802.11, in order to emulate the buildings of the city center.Furthermore, we compared the two protocols in different scenarios varying the global network density (GND) and average global node speed (GNS).By global network density we mean the total number of vehicles in the entire simulation time, the network density was varied from 100, 150 and 250.We only simulated up to 250 vehicles due to computational 20   resources and time constrains.For example doing a simulation run with 250 vehicles took around 5 days and simulating 350 vehicles generated simulation runs taking a whole month.Extending the simulations results with higher GND values is desirable thus regarded as future work.
As for the average node speed we are referring to the average speed of all the vehicles in the network, during all the simulation time; we present results with GNS of 10, 15, 20, 25, 30 kph.The reason the speed values resulted so small is because the vehicles spent a lot of time in stops and traffic lights.In addition, we generated the maximum feasible number of CBR connections between the vehicles in the simulation area, which is less than half the total number of nodes in the simulation, the CBR connections were active during all the simulation time.Additional simulation parameters are shown in Table III.In Fig. 21 we present the results comparing the Adaptive OLSR versus the Normal OLSR.In the upper charts we measured the goodput of the two protocols in respect to the various speed (GNS) values, and we did this for each of the three node density (GND) scenarios taken into account.In the lower charts we measured the normalized routing overhead (NRO) between the two protocols with respect to the different values of GNS.
Concerning the goodput metric, we can say that the goodput of the Adaptive OLSR closely mirrors that of the Normal OLSR, nonetheless generating less goodput.Doing an overview analysis of all the measurements with the different GNS and GND values, we concluded that in average the Adaptive OLSR goodput is 1.42% less than the Normal OLSR; this means that the adaptation of case study 1 generated worse performance than the Normal OLSR.However this conclusion lacks precision because the resulting confidence intervals are not small enough.Increasing the number of runs is needed to provide this certainty.
Regarding the NRO metric, we can see a clear advantage of the Adaptive OLSR in every scenario because it produces less control packets.In this case the confidence intervals are small enough to provide us with this certainty in spite of only doing five runs.Nevertheless, we notice that the bigger the speed (GNS) value, the advantage of the Adaptive OLSR begins to diminish.Doing an overview analysis of all the measurements with the different GNS and GND values, the Adaptive OLSR NRO value was an average of 20.78% less than Normal OLSR; this means that the adaptation of case study 1 generates 20% less control packages given that both generated almost the same goodput.
In summary the adaptation of case study 1 generated an improvement by reducing by 20% the number of control packages of OLSR, at the cost of reducing its goodput by approximately 2%.

C. Scalability of the PLUGAM architecture and comparison against an existing adaptive protocol
Finally, to get a better grasp of the performance and efficiency of the adaptation middleware architecture, in this section we discuss its scalability and do a comparison with an existing adaptive protocol.
We refer to the scalability of the PLUGAM in two aspects: first based on the number of nodes in the network, and secondly based on the number of NL protocols used in the middleware instance by the user.Regarding the scalability with respect to the number of nodes/vehicles in the network, we observed the following: • Each node in the network has one middleware instance installed, each one contains the same context elements, NL protocols, plug-ins, adaptation solutions, applications, etc.The current focus of this architecture is offering only node-local adaptations, this means that PLUGAM architecture is a purely distributed system, which in principle has better scalability than a centralized system.The definitions of node-local and distributed adaptations can be found in Section II.• If the architecture were to be extended to deal with distributed adaptations (regarded by us as future work), then it would not be a purely distributed system anymore.Distributed or global adaptations need centralization or additional interactions between nodes to coordinate adaptations, this would surely impact the scalability with respect to the number of nodes.
Regarding the scalability with respect to the number of NL protocols used in PLUGAM middleware, the generic aspect of the architecture generates extra overhead in contrast to particular adaptive protocol solutions, every NL protocol added generates the following extra costs: • Each NL protocol, same as the other extension components of the architecture (context elements, vehicular applications, adaptation configurations, etc.), incurs additional memory overhead due to the need to attach meta-information that the middleware uses to manage them.This is the cost of modularization and low coupling design of the extension components.Related to having a high number of adaptation solutions in the middleware, this increases the probability of having adaptations interfere with each other producing unexpected results, thus special care and experimentation is needed to calibrate the effects of the adaptation solutions added in them.The scalability of the architecture is also dependent of the plug-in platform efficiency in regard to loading a high number of plug-ins, especially in the initiation step in which all the plug-ins are loaded (our prototype gave us initiation times of around two seconds).In the case of the prototype's plug-in platform based on OSGi/iPOJO, no serious scalability analysis has been found in the literature, however OSGi has been used to build programs (e.g.Eclipse) supporting a high number of modules.Furthermore, to get a more comprehensive view of the performance and efficiency of PLUGAM we emphasize on the extra overhead generated by our generic solution in contrast with a particular adaptive protocol.We will use as example the proposal of Chen et al. [20] which performs an adaptation based on switching between two different NL protocols (more information can be seen in Table IV of Section VII).The extra overhead generated by our generic solution is the following: • An additional processing cost exists due to the indirect access between the extension components involved in the adaptation solution, contrary to particular adaptive protocols like Chen et al.where these elements are tightly integrated and directly communicating.This processing cost mostly depends on the communication delay between plug-ins and the middleware passing through the plug-in platform, in our prototype implementation this delay is very small, around 0.009 ms as seen in Section VI-A3.data.The middleware header helps to support a multiple applications multiple NL protocols environment and identifies the NL protocol and application attached to the message.Chen et al. [20] not being a generic approach treats these two NL protocols as a single super protocol hence does not need this header.
• PLUGAM architecture generates a processing delay to setup and execute an adaptation solution; a particular solution like Chen et al. has direct access to the context elements values and only executes the adaptation algorithm.From Section VI-A2, the processing time to setup and execute an adaptation solution in the prototype is inferred to be less than 0.2 ms.• Particular adaptation solutions like Chen et al. do not include a concurrent processing overhead generated by the context manager subsystem.

VII. RELATED WORK
There have been several adaptive protocols proposals for mobile networks which have shown their efficiency in dealing with changing environments.In Table IV we present few of these adaptive protocols by highlighting their association to their possible implementation using our adaptation middleware architecture.
We found that most of these adaptive protocol proposals were self-contained, meaning that the proposals are usually promoted as another novel Network layer protocol which handles better the dynamism of the network, nevertheless no work is done to relate their adaptation solutions to other proposals nor to propose a common adaptation model; this makes it difficult to promote the reuse of parts of their solution or ideas.Furthermore we also notice that their adaptation solutions are very specific to a particular NL protocol.That is why the aim of our work is to promote the generalization of adaptation solutions independent of the NL protocols and context variables by means of proposing a subsystem in the form of a middleware and based on an adaptation model.

Besides the adaptive protocols found in MANETs and
VANETs, there is some related work on subsystems or middleware proposals aiming to improve the performance of NL protocols and applications to dynamic conditions.
From the point of view of using context information to produce more dynamic applications and communications, Peddemors et al. [26] proposed a platform to express and provide context information to mobile applications; the platform allows applications to read the context variables or act upon them by adapting their behavior.Salber et al. [14] proposed the use of a context widget to represent and provide applications access to context information.The context widget platform provides a standard subscription mechanism and a polling mechanism.The context widget architecture includes composition of context information or context fusion acquired from multiple distributed sources.
The previous context platforms only focused on offering context to applications and not to Network layer protocols as we are proposing, and the authors gave no further details on how to perform the adaptation of the application behavior once the context information is obtained.However their context model is more complex than ours.
On the other hand, there are other subsystem type proposals which offer a way to adapt the communication system by switching network protocols or reconfiguring them from within (using a compositional adaptation approach).For example Nundloll et al. [4] proposed a framework for run-time reconfiguration of routing protocols for VANETs.This framework encapsulates a network layer protocol in a component and also separates it in sub-components using a Control-Forward-State (CFS) pattern.This framework adapts or reconfigures the protocols by making changes at two levels: add / remove the protocol components (switching NL protocols), or change CFS sub-components within the protocol.The authors also identified some common Network layer protocol operations where adaptations can be performed, these operations are the send, receive messages, scheduling tasks and neighbor discovery.This framework for protocol reconfiguration has also been applied to other types of networks (Wireless Sensor Networks [27] and MANETs [28]).Furthermore, MANET researchers have developed a number of reconfigurable ad hoc protocol frameworks, prominent among which are ASL [29] and PICA [30].
Comparing these compositional adaptation proposals to our adaptation middleware, these works require a full reimplementation of NL protocols to take advantage of interchanging their internal components at run-time.In contrast, our adaptation middleware architecture is based on the parameter adaptation approach, and porting already existing NL protocols is more simple because it only requires to implement the protocol plug-in interface.Another difference is that our middleware proposes the use of multiple NL protocols running concurrently in the Network stack, contrary to these other works which only consider having one active NL protocol at a time.Finally Nundloll et al. [4] framework proposal also does not offer a concrete solution on how to express and use the obtained context information, as does our middleware solution.

VIII. CONCLUSIONS AND FUTURE WORK
We have presented PLUGAM, a middleware that handles the adaptation of the Network layer protocols in a vehicular system; the aim of this paper was to explain the middleware architecture in detail.In particular, a novel modeling of the adaptation concept applied to NL protocols is presented, and this model is used as the basis of the middleware.The adaptation middleware is a general solution to help built a set of adaptive protocols found in the literature.Not all the adaptive protocol proposals can be built with our architecture, however the architecture is flexible enough to be easily extended by adding more adaptation modes, special adaptation actions.The definition of the architecture is guided by the provision of two key types of adaptations to NL protocols: one is to modify the NL protocol behavior by adaptation based on context information of the node, and second is to propose a multiple NL protocols environment (where more than one are running concurrently in the system) and allowing adaptations where a selection between them can be made based on context information.Furthermore, we assess the feasibility of our approach with two distinct case study examples of adaptive protocols which can be built with the middleware, and each represent the key types of adaptations mentioned above.We also conducted via simulation a short analysis of the performance of the case study 1 adaptation in order to assess the reported improvements.Although the proposed case study 1 adaptation was far too simplistic, the results show that the adaptive version of OLSR produces 20% less control overhead than Normal OLSR, and only lowering the goodput by 2% to that of Normal OLSR.In addition, to demonstrate feasibility of the middleware architecture, we implemented a prototype along with a set of plug-ins examples, our main concern was to see if using a plug-in platform to interconnect the extension components of an adaptive protocol is a feasible solution.The chosen plug-in platform for the prototype was implemented using OSGi and iPOJO technologies.
To get a rough idea on the cost and performance of the adaptation middleware, we presented some measurements done to the prototype and analyzed the memory and processing overhead of using the middleware.Results show that the prototype's RAM (20 MB) and ROM (111 MB) usage is small enough to make it viable to implement the adaptation middleware in hardware similar to today's medium entry level smartphones having a Java virtual machine.In terms of processing overhead of the prototype, the results indicated that the latency to execute an adaptation solution in each of the adaptation modes are around 0.5 to 1.5 ms, which in terms of network protocols is acceptable.These times where measured on a 1.6 GHz dual core processor, which correspond to the processing power of today's high-end smartphones, this means that to guarantee similar latencies the future vehicular systems need at least this processing power.We think that vehicular systems with similar hardware specs are feasible to appear in a few years.
We also analyzed the cost/performance of only the plug-in platform of the prototype.The analysis shown, in particular that of OSGi and iPOJO technologies, have a very small processing overhead; we think this was the main reason of the small processing overhead results of the adaptation middleware prototype.Although we have noticed that other plug-in platforms are not as lightweight as the OSGi and iPOJO technologies.
The adaptation middleware architecture we have presented is part of an ongoing project, and we are working to accommodate a wider range of adaptive protocols and improve the basic context and multiple NL protocols environments.Specific aspects we want to explore and thus regarded as future work are: • The adaptation middleware is limited to building node/local adaptations, as future work we want to explore extending the architecture to also allow distributed or global scope adaptations.• Explore using a more complex context environment, in particular explore the use of context ontologies to allow the declaration of a type of context element to fit an input slot of an adaptation algorithm without specifying the context source; also explore the fusion of context information to produce new context information, and finally add context information history to refer to the last values of a context element.• Introduce message-specific context elements in which the current value of the context is tied to a message.For example have a priority of the message context element, have the location context information of the node that relays the message.• Introduce mechanisms to validate the run-time effects of an adaptation in the system, or at least provide some feedback of the effects.This could help speed up the calibration of adaptation solutions built with our middleware in order to improve performance.In this appendix we present the definition of all the different plug-in interfaces in the architecture which were mentioned at the end of section III-D.These interface definitions are shown in Fig. 22.The IContextEPlugin interface contains the methods to build a contextE plug-in.The IProtocolPlugin interface contains the methods to build a protocol plug-in.The IAlgorithmPlugin interface contains the methods to build an algorithm plug-in.And finally the IApplicationPlugin interface contains the methods to build an application plug-in.ACKNOWLEDGMENT Partial funding for this work was provided by the Mexican Council for Science and Technology (CONACyT).This work is also funded by the ANR research agency (France) within the scope of the Optimacs project.

CONFLICT OF INTEREST
All the funding sources for this work are listed in the acknowledgement section of the paper.None of the authors of this work have a significant financial relation or affiliation with any product or trademark mentioned, nor any potential bias against another product.

Fig. 1 .
Fig. 1.Entity/Relationship model of the relationship of the elements of the adaptation solution

•Fig. 4 .
Fig. 4. UML ER diagram showing the relationship between the types of plug-in and the extension components

Fig. 5 .
Fig. 5. IPlugin interface definition and the relationship with the plug-in types

Fig. 6 .
Fig. 6.Definition of the ElementIdentifier class a) and the meaning of its attributes b)

Fig. 8 .
Fig. 8. Adaptation middleware position in the OSI model

2 FilterFig. 9 .
Fig. 9. Graphical representation of the special adaptation actions switcher and filter

Fig. 10 .
Fig. 10.Definition of the AdaptationMiddlewareMessage class and the IMiddlewareProxy interface

Fig. 11 .
Fig. 11.UML sequence diagram of the registration of an application by the middleware

Fig. 12 .
Fig. 12. Implementation of the extension components needed for case study 1 in the adaptation middleware

Fig. 14 .
Fig. 14.Scenario of case study 2 proposing a switch between network layer protocols

Fig. 15 .
Fig. 15.Implementation of the extension components needed for case study 2 in the adaptation middleware

Fig. 17 .
Fig. 17.Graphical description of the run-time behavior of the middleware executing the adaptation configuration of case study 2

Fig. 18 .
Fig.18.Apache Felix running with the adaptation middleware bundle, the pluginServices bundle and the PLUGAM plug-ins of case study 1 which are shown in blue(2) Fig 19  show the processing time measurements of the CUPIB adaptation mode.The chart c) shows the processing times by varying the number of adaptation actions and fixing the algorithm load to NONE and the context elements to one.Chart d) shows the processing times by varying the number of contexts elements of the algorithm, then fixing the algorithm load to NONE and the number of adaptation actions to one.

Fig. 19 .
Fig. 19.Measurement results of the processing overhead of the adaptation middleware prototype

Fig. 20 .
Fig. 20.Chosen road network for the simulation of case study 1

•Fig. 21 .
Fig. 21.Simulation results of case study 1 represents the future value of the HELLO INTERVAL constant in milliseconds (2000 milliseconds is the default value in OLSR).The N = 7 pairs that we selected are shown in tableI.

TABLE I TABLE SHOWING THE
(v i , f (v i )) PAIRS PROPOSED FOR THE ADAPTATION ALGORITHM OF CASE STUDY 1

TABLE II ESTIMATION
OF END-TO-END DELAY OF PLUGAM MIDDLEWARE FOR A GENERAL UNICAST AND DISSEMINATION TYPE NL PROTOCOL.
SUMO Simulation for Urban Mobility: http://sumo.sourceforge.net/21Openstreetmap:http://www.openstreetmap.org/ • Each NL protocol, same as the other extension components of the architecture, are encapsulated in a plug-in.To create a plug-in extra special code and instructions need to be added in order to enable a communication channel with the plug-in platform.In addition, extra memory overhead is needed in order to implement the protocol plugin interface.Measurements for Section VI-A3 indicate around a 3.5 KB increase in code size.
• A mechanism deal with possible NL protocols interference if they use the same communication channel.• Propose a general node addressing scheme to unify or translate source and destination addresses between the different types of NL protocols supported by the middleware (to remember why this is useful see section III-G).• Introduce new adaptation modes; for example one that executes an adaptation solution in a NL protocol or vehicular application event, or when certain values of context elements are met.