The emerging SDVN (Software Defined Vehicular Network) paradigm promises to bring flexibility and efficient resource utilization to vehicular networks, enabling the emergence of novel Intelligent Transportation Services. However, as it was initially designed with wired network in mind, applying the SDN paradigm to a vehicular context faces new challenges related to the peculiar characteristics of this network (high node mobility and node density, and the presence of wireless links). In this paper, we focus on one of the critical architectural elements of SDVN, namely, the SDN Controller Placement, and promote the use of dynamic placement methods that take into account the dynamicity of vehicular networks' topology. We also describe the different approaches towards a dynamic controller placement and also propose an ILP (Integer Linear Programming) based dynamic placement method that adaptively readjusts the number and placement of controllers according to road traffic fluctuations. The proposed method is evaluated using a realistic traffic trace from Luxembourg City. Simulation results show that our approach outperforms the static approach as proposed in the literature.Most existing research work have been elaborated on the opportunities that the SDVN concept could bring when applied to vehicular networks [10]. However, some challenges need to be addressed to reach these expected opportunities. Among these challenges, we mention firstly, the network topology discovery, which is a crucial service in the Software Defined Vehicular Netowrk (SDVN) system [11]. Its main goal is to build and maintain an up-to-date view of the underlying network. The density and high mobility of vehicles make the design of this service a challenging task. Secondly, the connectivity between the vehicles and their controller is partly wireless [12]. In fact, vehicles can go through areas without network coverage, this could make the controller temporarily unreachable, which may impact network performance. Thirdly, the mobility of vehicles can result in frequent changes of their attached SDN controller. This impacts the established sessions with the initial controller, as well as an increase of network overhead due to inter-controller vehicles information exchange. The SDN controller placement is a key architectural element that can help mitigating the above mentioned challenges. It consists of computing the number of SDN controllers to deploy and derive their placement in the network. This choice must be done appropriately given the critical role of an SDN controller in this architecture. First, wireless link connectivity and quality must be considered in order to minimize the connectivity losses between vehicles and their controllers. Second, the SDN Controller coverage should be defined carefully taking into account the density and mobility of vehicles. This helps avoiding SDN controllers' overload as well as improving the performance of vehicle-to-controller communications, and also, minimizing the number of changes in the set of deploy...

Technological advances such as miniaturization of sensors, mobile devices and increased computational capabilities have given way to Context Aware Applications (ACC), which constantly monitor and change depending on the context. These applications require a variety of features and services, particularly on the management of context. When applications/services lack part or some of these services, they must be consumed from other suppliers who can provide them via a middleware. In addition, due to the changes undergone by the context mean that such services consumed by the ACC must be dynamic; and due to the amount of data involved to define the context, it may require more computation capacity than that provided by a mobile device. For these reason it is necessary the use of the Cloud. In this way, to support these requirements is proposed CARMiCLOC (Context Awareness in Reflective Middleware Cloud Computing), a web-service based middleware, which can behave as a SaaS (Software as a Service) or as a PaaS (Platform as a Service).

No abstract