Smart and intelligent network selection approach to support location-dependent and context-aware service migration

Abstract

Vehicular networking has gained considerable interest within the research community and industry. The automotive industry is supporting the notion of pervasive connectivity by agreeing to equip vehicles with devices required for vehicular ad hoc networking. Equipped with these devices, mobile nodes in vehicular ad hoc networks (VANETs) are capable of hosting many types of applications as services for other nodes in the network. This research focuses on addressing the challenges of location-dependence, intermittent network connectivity and irregular network traffic flows in unplanned areas for VANETs to host and operate non-safety-critical VANETs services. We assume unplanned areas as the one that lack communication infrastructure and planning. Such areas observe irregular vehicular traffic on the roads as well as on the networks. This research investigates the shortcomings of location-dependence, intermittent network connectivity and irregular network traffic flows and addresses them by exploiting location-dependent service migration over an integrated network in an efficient and cost-effective manner.

Keywords

LDCAMS cooperative & cost effective network selection algorithm (CACENSA)VANET deployment VANET services network Integration WAVE UMTS

1. Introduction

Vehicular ad hoc networks (VANETs) are expected to have great potential to support safety, security, traffic and comfort related services. However, the provision of such services in an unplanned area is a challenge. Unplanned areas are defined as the areas that are characterized by being developed in contradiction to planning regulations of concerned authorities. Thus, such areas, in essence, lack services and infrastructures. With economic growth in developing countries, unplanned land development is likely to take place. As a result, spatial unplanned distribution of cities, towns and villages will be found in developing countries. The urban network of cities, towns, and villages encompass all aspects of the environment within which societies’ economic and social interactions take place. This research assumes unplanned areas as the areas that are not equipped with road-side communication infrastructure for vehicle to vehicle communication. In developing countries such areas are required to be monitored in several security-related and emergency related scenarios. VANET services provide cost-effective means to serve these objectives. Provision of VANET services in unplanned areas is important, however, the deployment of VANET services in such areas lacking dedicated fixed road-side communication infrastructure, poses several communication challenges, such as Vehicles communication range: Vehicles may go out of each other’s communication range. Vehicle’s distribution on the road may be irregular. There might be very few vehicles on the road so vehicle to vehicle connectivity can be an issue. Because of lack of vehicular traffic planning, there can be high vehicle traffic and/or low vehicle traffic scenarios. In case of high vehicle traffic scenarios, high network traffic or network congestion is likely to be observed. Sharp road turns, hilly areas, unplanned buildings on the roadside offer vehicle to vehicle communication hurdles. In unplanned areas it is hard to predict vehicular traffic and network traffic thus, the advantage that can be obtained by early predictions of traffic is hard to take. It requires high cost to install fixed road-side communication infrastructure for vehicle to vehicle communication. All these situations involve either degrading the performance of the communication network for vehicles or raising the deployment cost of such networks. Thus, the deployment of VANET services, in general, is a challenge.

Intermittent network connectivity in VANET may limit the availability of VANET services. Moreover, the quantity of network traffic produced from vehicles in unplanned area varies to a large extent. The variations in the network traffic can lead to network congestion and, as a result, can degrade VANET services. The problem is further exacerbated when services are location-dependent i.e. they have to be provided in a designated proximity.

To address the issues of intermittent network connectivity, network congestion due to irregular traffic flows and location-dependence, the automobile industry has agreed to provide multiple network technologies, such as Wireless Access in Vehicular Environment (WAVE) and Universal Mobile Telecommunication System (UMTS) in vehicles. The significant challenge, however, is to provide availability-efficient (here availability-efficient explicitly means better availability i.e. increased availability of VANET services yields better VANET service efficiency) and cost-effective, location-dependent services over these networks. Existing VANET strategies are not adequate to provide availability-efficient and cost-effective location-dependent VANET services in unplanned areas.

The provision of location-dependent VANET services in an unplanned geographical area is possible. One approach for such provision is via deploying location dependent context aware migratory services; however, the deployment of such services largely depends upon the performance of the underlying network. This research attributes the performance of the underlying network through an additional backup network to support the service migration process. However, to keep control over the cost incurred by using an additional network, this research presents cooperative and cost-effective network selection algorithm. This algorithm not only supports cost effective network selection, but also decision making process for triggering service migrations. The details regarding context aware migratory services are presented later in this paper, however, it is important to note here that this is one way to deploy non-safety related VANET applications.

1.1. VANET application deployment

Non-safety-critical applications can also be classified with respect to their deployment, falling into location-dependent and location-independent applications. Location-dependent applications are deployed on nodes present in specific, targeted locations. When such a node moves outside the boundaries of its specific, targeted location, it becomes unsuitable to host this application. For example, a vehicle with a camera can take pictures of an accident scene but, due to its mobility, it will leave the location and become unable to host the accident reporting application. Location-independent applications can be deployed upon any mobile node, which possesses the required resources for hosting the services. Different types of resources are described later in this paper. Location-dependent, non-safety-critical applications can be implemented and deployed using several approaches. One common aspect of these approaches is that they employ and share their location awareness technique. One such approach is context-aware migratory services [35]. Unlike a regular service that always executes on the same node, a context-aware migratory service can migrate to different nodes in the network in order to accomplish its task. Further details about context-aware migratory services are discussed in later in this paper.

Vehicles can collect information and forward this information to neighboring vehicles. There are many possible sources of such information. For example, vehicles can be provided with sensors to collect information, such as road grip, temperature and hazard detection. Vehicles can also be equipped with GPS devices to know their position and direction. The other primary source of information is the driver, who can provide information such as the destination and intended route for reaching the destination. Applications can be deployed on vehicles to gather such information and use it to support the driver as well as to enable cooperation with other vehicles so as to reduce the number of accidents. Before describing the research motivation, the next section presents and classifies resources that are required to deploy VANET services in an unplanned area.

1.1.1. Data collection resources

Newly manufactured vehicles are equipped with many sensors and other equipment like cameras etc. Vehicles collect data directly using such equipment. Examples of such equipment include temperature sensors, road status sensors which can detect if roads are slippery, visibility sensors and special purpose cameras for capturing live videos and images.

1.1.2. Communication resources

The vehicle industry has shown an interest to equip vehicles with communication resources. These resources include several types of network cards and antennas with transmitters and receivers. The automobile industry has agreed to equip new vehicles with multiple communication capabilities. This research focuses on two major network technologies i.e. UMTS and WAVE.

1.1.3. Computational and data storage resources

In VANETs there is no hard power limitation, thus vehicles can be equipped with computational and data storage resources [8,31]. This capability enables a number of useful applications in VANETs.

2. Literature review

There are several efforts that have been made to investigate VANET deployment and communication issues. Furthermore there are several contributions to support code offloading. This section presents a brief overview of some of these research projects and also presents a critical review of the above mentioned contributions.

2.1. FleetNet (2000–2003)

The FleetNet project was supported by academia and the vehicular industry in Europe. This project investigated requirements, design decisions, and challenges of vehicular networks. It considers provisioning of safety-critical and non-safety-critical applications. This project motivates the use of UMTS as the communication network among vehicles as well as providing integration of VANETs with the Internet. To achieve this communication and integration, this project investigates the challenges that are involved at the MAC and Routing levels. The major areas that are investigated in this project includes new routing and MAC level protocols for VANET communication [13,16]. The Fleetnet project promoted the choice of UTRA-TDD to be used as communication hardware. However, the time criticality of VANET safety-critical applications makes it a poor choice as it hardly meets the critical time requirements of safety critical applications [29].

2.2. Car-to-Car Communications Consortium

This project started in 2001. The major objectives of this project were the development of an open standard for cooperative vehicular communication to support development of safety and non-safety critical applications [6]. This project is investing its efforts to develop a European standard for regulating vehicle to vehicle and vehicle to infrastructure communication in Europe. This project is particularly focusing on validation of vehicle to vehicle communications and its integration with vehicle to infrastructure communication to provide non-safety critical applications. This project also considered investigating the deployment strategies and development of business models to increase market penetration of vehicular communications. Moreover, this project considered a planned area for the deployment of VANETs and provisioning of safety and non-safety applications. In particular, the deployment of location dependent services seems to be an ignored area in this project.

2.3. Vehicle infrastructure integration (VII)

The project VII (2004-2009) is a collaborative effort of academia, manufacturing industry and IT service providers. This project considers issues involved in deployment of infrastructure to support vehicle to infrastructure communication. This project also explores some of the issues that are involved in vehicle to vehicle communication for a variety of safety-critical and non-safety-critical applications. In particular, this project explores development of VANET applications which can contribute to gaining the interest of vehicle manufacturers [1,45].

2.4. Vehicle safety communications (VSC)

This project has been supported by the U.S department of transportation in two phases i.e. VSC (2002–2004) and VSC-2 (2006–2009). This project explored experimentation with safety related applications so as to improve automobile commuting by using DSRC (Dedicated Short Range Communication) and other supporting technologies. This project considers several driving scenarios and on the basis of impact of driving events on road safety, it classifies applications in several categories. This project is focused on issues that are involved in provisioning of safety-critical applications. For achieving significant safety, this project exploits vehicle to vehicle communications. This project claims to reduce the number of accidents and injuries by 76% per annum. This project does not consider the issues that are involved in provisioning of non-safety-critical applications [5].

2.5. Intelligent vehicle initiative (IVI)

This project intended to reduce the number of road accidents exploiting vehicle to vehicle communication to avoid various driving mistakes [17,18]. This project considers identifying driving distraction events by examining crash data. Various types of crash events were selected to study. Identification of root causes of these distractions helps in determination of crash avoidance systems to reduce the number of such accidents. This research considers safety critical applications and again the provision of non-safety-critical applications are ignored [18].

2.6. Network-on-Wheels (NOW)

NOW is a project supported by the German government, industry and academia. The major contribution of this project is to investigate optimal performance of message communication among vehicles on the road. Additionally, security mechanisms for data transfer among vehicles has also been researched [11].

2.7. PRESERVE (2010–2014)

This project is aimed at provisioning of a complete security system that should provide protection to the entire vehicular communication system. A vehicular communication system includes all communication components ranging from sensors attached to the vehicles, on-board networking units, V2V/V2I communication components, and the receiving application. PRESERVE is an effort to provide a complete, scalable, and cost-efficient V2X security subsystem that can be integrated with other, ongoing VANET projects to provide Cooperative ITS and V2X communication for a new age of safer, more efficient, and more comfortable road traffic. The PRESERVE project is not very closely related to this research, as its much more focused on security issues involved in VANET projects, however, in the future, the PRESERVE project may be integrated with this research to secure deployment of location dependent migrating services [10,12,25].

2.8. Sim TD (2008–2013)

This project intends to provide increased road safety and an improved traffic system by exploiting vehicle to fixed infrastructure communication. This project provides real test beds to perform experiments at large scale to test deployment scenarios of VANETs in Europe. This project considers the availability of road side infrastructure so as to deploy the safety and non-safety applications in Europe; however, in unplanned areas this assumption is not realistic. Particularly, the deployment of security related applications in unplanned area is a challenge that cannot be met by the assumptions taken in this project [40].

2.9. SAFESPOT (2006–2010)

SAFESPOT is another European project that considers issues involved in several areas of intelligent transportation systems that uses vehicular communication. The project is subdivided into sub-projects to address safety and non-safety-critical applications. This project considers the availability of road side infrastructure for vehicle to infrastructure communication for provisioning of non-safety critical applications. However, parameters that characterize unplanned areas are not taken into account. Furthermore, this project does not investigate the cost-effective provision of communication for availability of safety and non-safety-critical applications [4,7].

2.10. Drive C2X (2011–2014)

DRIVE C2X focuses on communication among vehicles (C2C) and a roadside and backend infrastructure system (C2I). Previous projects such as PReVENT, CVIS, SAFESPOT, COOPERS, and PRE-DRIVE C2X have proven the feasibility of safety and traffic efficiency applications based on C2X communication. DRIVE C2X goes beyond the proof of concept and addresses large-scale field trials under real-world conditions at multiple national test sites across Europe. The systems to be tested are built according to the common European architecture for cooperative driving systems defined by COMeSafety, thus guaranteeing the compliance with the upcoming European ITS standards. This approach also ensures that the results of DRIVE C2X have long-term validity at the European level, giving system developers as well as decision makers in the industry and authority sides the necessary decision confidence.

For the first time in Europe, DRIVE C2X is also implementing and testing a concept for the integration of a data backend, therefore enabling commercial services based on C2X communication data to private and commercial customers. Such services are expected to become a major revenue source for cooperative driving systems and can be the key for successful implementation of this technology on European roads [28].

From the review of European projects, it is evident that the research community is actively pursuing safety-critical projects; however, there are few projects that considers provision of non-safety-critical applications as revenue generating applications. Provision of safety-critical and non-safety-critical applications has been proposed in two ways.

On a single communication channel with a single radio transmitter/receivers;

On separate communication channel with multiple radio transmitters/receivers.

Both approaches have their pros and cons. Provision of safety-critical and non-safety-critical applications with a single radio transmitter and receiver is a cost-effective solution. Moreover, it offers better utilization of bandwidth. However, this approach requires a complex priority mechanism to ensure network availability for safety-critical applications. Another drawback is that non-safety-critical applications may face the situation of starvation as if there are always safety-critical applications running and utilizing the complete bandwidth. Finally, switching a single radio from one channel to another requires time, so it may affect the performance of VANET applications in terms of time-delay. Provision of safety-critical and non-safety-critical applications with multiple radio transmitters and receivers is not a cost-effective solution. However, it provides better performance in terms of reliability. It is important to note that no work has considered provisioning of safety-critical and non-safety-critical applications in unplanned areas. Particularly provision of location dependent context aware migratory services in unplanned areas is not investigated. This research investigated the provision of these security-related applications in unplanned areas.

To support successful deployment of an efficient communication mechanism is thus required to support LDCAMS successful deployment in an unplanned area. Unplanned environments complicate communication as they lack roadside infrastructure for communication. Moreover, in developing countries that are economically poor, it is very hard to fund such infrastructures [33,44]. due to high-speed mobility, a vehicle may no longer be suitable to host the service [35]. Deployment of LDCAMS in unplanned areas faces several challenges. Systems offering LDCAMS deployment need to address the following issues:

Context-awareness: LDCAMS are required to be capable of dissemination and collection of context information of host and client nodes [23,26,35,41–43].

Service adaptation: LDCAMS are adaptive to changes in the context. In VANET, context information changes frequently due to high-speed mobility so it is vital for a service to adapt its behavior accordingly.

Resources discovery: LDCAMS faces a major challenge in the form of performing resource discovery [2,26,27,35]. Before the service migrates from one vehicle to another, it is vital to find out if the resources available at the target vehicle are sufficient to host the service successfully.

Service state capture and transfer: LDCAMS reduces the number of service discoveries. LDCAMS achieve this advantage through migrating the services as well as the list of client vehicles (addresses) from one node to another. For seamless relocation, the state of the service at the host vehicle is captured, and preserved, while migrating the service from one vehicle to another vehicle [32,41].

Offloading decision can be made statically or dynamically. In static decision, program is manually partitioned during the development process by the developer [30,38]. Major advantages of such static decision making is low overhead at runtime as the program does not has to decide which part of program to be executed. Disadvantage of static offloading decision is that, parameters must be accurately predicted in advance. Dynamic decisions adapts its decision dynamically at run time to adapt various external and internal conditions [35]. Prediction mechanism anticipate dynamic decisions for component execution time and battery consumption [39]. Disadvantage of runtime decision is that predictions added to the monitoring of the run-time conditions can lead to a high overhead. Current offloading techniques implements static analyzer, dynamic profiler and optimization solver that are all implemented on smartphones to cooperatively make optimized offloading decision [24]. Ionan et al. [15] proposed history based profiling of the applications both on server side and smartphone and uses the ratio of benefit to make offloading decision but practically, it is not possible to find the gain ratio in every possible combination.

Prior study conducted by Florer et al. [14] suggests that better response time and less energy consumption can be achieved with computation offloading. However, offloading is appropriate only when the offloading overhead and the server side execution cost is less than the local execution cost. Thus, offloading for every computational task may lead to a prolonged response time instead of conserving energy or improving response time. According to Florer et al. offloading is not a decision process; in fact it is a global learning process.

Khairy et al. [21] proposed Smartphone energizer: a context aware offloading technique based on the parameters such as device, user, service and network characteristic. Smartphone energizer uses Support Vector Regression (SVR) in order to optimize both the energy and execution time. Smartphone energizer optimizes both energy and execution time from 40% to 56% and execution time from 43% to 58% respectively. Smartphone energizer works in two modes i.e. learning and prediction mode based on contextual information. However the model does have a low accuracy which leads to wrong decision. Hassan et al. [19] uses Multi-Layer Perceptron (MLP) for classification. POMAC considers other resource information such as data size, CPU and bandwidth for offloading decision. It also uses feedback channel for self-learning, which leads to more time and energy for training the instances.

Heungsik et al. [9] has proposed an online learning mobile offloading framework to support flexibility policy known as MALMOS (Machine Learning-based Mobile Offloading Scheduler with Online training). MALMOS compared three classification algorithm, instance based, perceptron and naïve Bayes in terms of training time, classification time and scheduling accuracy. Although MALMOS is light weight and easy to train but it’s biased towards previous observations and assumes features to be independent of each other.

Ul-Amin et al. [37] presented mechanism for network selection to migrate service among mobile devices over high speed networks such as VANET. The approach did not consider cloud as one of target option. Although the above mentioned approaches considers dynamic features from the application and network level (network bandwidth) to predict remote execution time and data transfer time but the machine learning techniques they use provide inaccurate decision which in turn leads to high energy consumption and degrades the performance. In contrast, in this paper, SVM classifier for making decision whether to execute the component locally or remotely was used.

Fig. 1.

Block diagram of the user device for the integrated network architecture for deployment of LDCAMS.

3. Research methodology and system design

The lowest layer in Fig. 1 shows the technological components for communication such as satellite for providing location information to vehicles through a GPS module integrated in vehicle. Furthermore, it shows a WAVE module integrated in the vehicle communicating to WAVE module integrated into another vehicle. Thus, vehicle-to-vehicle communication using WAVE modules can be achieved without any external infrastructure. The third module for communication presented in this architecture is a UMTS module.

Fig. 2.

The proposed architecture to support deployment of LDCAMS.

3.1. Core system design

Figure 1 shows a UMTS base station that may support communication among vehicles. However, the decision to choose UMTS or WAVE network for LDCAMS communication is made through execution of a cost-effective network selection algorithm presented later in this paper. A central framework shown in this figure is processing and communication module (PCM). PCM has responsibility for collecting the required information, such as neighbour information, vehicle location, speed, road condition, weather condition, vehicle destination and network related information based on information collected, PCM is responsible for executing the network selection algorithm. The PCM Framework to support LDCAMS is presented in Fig. 2 and is discussed later in this paper. Two more modules that may be seen in Fig. 1 are an in-vehicle memory unit and in-vehicle sensor based information. The in-vehicle memory unit is responsible to keep data that is either generated by running applications or received from another vehicle. The second module i.e. in-vehicle sensor based information module, takes the responsibility to collect relevant information using sensors within the vehicle. Examples include temperature sensors, and road grip sensors. The top module shown in this figure is the human machine interface. This enables a user to give inputs and receive outputs. For example, a user may see as collision warning on the screen that is integrated in this module. The PCM is interfaced with rest of the modules to help obtain vehicle dynamic data, interacting with drivers, the GPS unit to obtain geographic location and timing reference, as well as any application logic. The cost-effective network selection algorithm is implemented in the communication framework in order to reach the optimal complementary effect of both technologies i.e. WAVE and UMTS.

3.1.1. Processing and communication module (PCM)

Context-aware service migration with single network support has been proposed in [34]. LDCAMS are capable of migrating to different nodes in the network while preserving and maintaining the state of communication with clients. Such a service migrates from one node to another, reducing the number of service rediscoveries. When the service migrates from one hosting node to another node, the state information of the service may also need to be migrated. Although service-migration has these advantages, a single network (i.e. WAVE) is highly dynamic in nature; furthermore, the high-speed mobility of vehicles, particularly in unplanned areas contributes a high number of frequent disconnections. Thus, for successful migration of LDCAMS, multiple integrated networks in integration may be used. UMTS is one of the choices for secondary network support for LDCAMS migration and communication. However, the cost to use UMTS may be significant. Thus, an efficient and cost-effective network-availability algorithm is required. This dissertation presents an integrated network solution to support LDCAMS deployment over VANETs operating in unplanned areas.

The simulation results that are presented in this paper show how this system architecture with the proposed algorithm (CACENSA) performs better in real life scenario particularly in unplanned geographic areas. The Block diagram of user device for the integrated network architecture for deployment of LDCAMS is presented in Fig. 1. One of the important elements shown in Fig. 1 is PCM. The proposed system architecture of PCM to support LDCAMS in unplanned areas is shown in Fig. 2.

The proposed architecture to support deployment of LDCAMS shown above is multi-layered. Lower layers of the framework provide management of multi-homed devices. The upper middleware collects and provides decision capabilities for service adaptations, migration, and switching of the network. This research paper is restricted in scope to cover the integration of WAVE and UMTS networks to support LDCAMS migration. In the next section, a brief description of the proposed architecture is presented. The scope of this research paper does not provide development and validation of all the components shown in this architecture; however, it presents functional details of several modules as shown in the architecture in Fig. 2.

3.1.2. Wireless network device manager

Wireless network device manager is a module in the proposed PCM framework to support multiple wireless networks. This research considers WAVE and UMTS networks to support LDCAMS. The Wireless network device manager is responsible for selecting one network at a time. The network selected for LDCAMS depends upon decisions made by communication manager. Communication among modules located at different layers shown in Fig. 2 takes place via Service Access Point (SAPs). The concept of SAP is taken from OSI reference model.

3.1.3. Operating system

The operating system layer shows the availability of operating system level functionality to support LDCAMS migration and communication.

3.1.4. Distributed computing platform

Distributed computing platforms support the development and execution of LDCAMS. DCP generally is located at upper layer of operating system as middleware. It provides abstraction for the development of applications/services such as LDCAMS. In addition, DCP coordinates with operating systems for accessing system resources such as execution of services etc. As a middleware, DCP addresses the underlying heterogeneity, either at hardware or at operating system level, for development of mobile services in ad hoc networks. There are several approaches of how DCP functions. In this proposed architecture, the choice of DCP also offers a location-dependent, context-aware service migration mechanism from one node to another node.

3.1.5. Communication manager

The communication manager acts as the brain of the system. The Communication Manager module is responsible for making decisions based on context and resource information that is gathered through the context and resource monitors. Within the scope of this research, the communication manager is designed to implement two functionalities.

Collecting network congestion information using a simpler approach presented in another paper out of this research [37];

Making network selection based on a cooperative and cost-effective network selection algorithm contributed for LDCAMS migration.

In addition to the functionalities implemented in this research work, it is proposed to implement communication manager as set of sub modules, each of the sub modules. The other tasks that the communication manager performs are:

It is responsible to consider resource level agreements that are made among different nodes;

The communication manager tracks available resources and resource demands of running services. Based on this information, the communication manager can initiate service adaptation, service migration and network handover.

The Communication manager takes the decision if the service needs to adapt its behavior to avoid complete service failure in case of limited available resources. The Communication manager has the capability to command the service to migrate to some other node. During communication, if the WAVE network is unable to meet the QoS challenges, communication manager calls the handoff manager to perform the network handoff.

Process System (PS): This process is responsible to check if the current host is able to host the service for a minimum duration of time that is defined depending upon type and size of the service. Based on information that is collected from system, this process may reach one of two possible conclusions:

Yes, the system is able to host the service;

No, the system will not be able to host the service due to changes the location and other context parameters.

If the system concludes (a), then system will continue to host the service until the next check is run. However, if the system concludes (b), then system needs to select next node (vehicle) to host the service for a defined minimum duration of time. The detailed selection algorithm of the next hop is assumed to be out of scope of this research. However, it is considered that next hop selection involves the availability of network resources as one of the major parameters. In this research, selection of the next node is executed manually by creating a node at specific geographic location. The process of next hop selection is shown as “Discover System” in the flowchart.

Process Network (PN): This process is responsible to check if the current network is able to discover a new host or to support service migration to the next host. In addition, PN periodically checks the available network status to ensure the current network meets minimal QoS requirements to support LDCAMS migration and other management processes, such as the next host selection process. Based on information that is collected from the system, this process may reach one of the two possible conclusions:

Yes, the network can support service migration;

No, the network cannot support the next host selection or service migration. Furthermore, this process may conclude that the network is not even meeting QoS requirements for currently running services.

If the system concludes (a), then the next process of ‘discover the new system’ is executed. After the selection of the next host, the system decides if there is a need of handoff to consider the cost of network. However, if the system concludes (b), then the system needs to select an alternative network.

Process Management (PM): The process takes the values from the two processes defined previously and manages the execution of functionalities, like triggering handoff and triggering service migration.

The flowchart in Fig. 3 shows that the communication manager continues to process the context information gathered by the context manager and decides if the node hosting the LDCAMS is still suitable to host the service for a defined minimum time. In addition to the suitability of location, the communication manager reviews the network conditions and capabilities of neighboring communicating vehicles. If network conditions of the WAVE network falls below a minimum threshold value predefined by the system, the communication manager can trigger the handoff and switch to the UMTS network for more reliable communication. If the communication manager finds out that the node hosting the service is going to be out of the specified location of the service, it discovers a new node to host the service. The communication manager uses information gathered through the context monitor and resource monitor to decide what node is in the best position to host the service. An important assumption made here is that vehicles that agree to cooperate in communication makes resource level agreements. From resource level agreements, the Communication manager decides which node has sufficient resources to host the particular LDCAMS. After the node is selected for hosting the LDCAMS, service migration is initiated by triggering service migration. To manage state-full service migration, the session manager is invoked. The communication manager guarantees the use of WAVE when it is available and meets the minimum predefined quality of service parameters. Network switching also depends upon the network capabilities of neighboring vehicles. Neighboring vehicles may have different network capabilities. Depending upon the cost and criticality of information being provided by LDCAMS, network-switching decisions are taken. A few exemplar scenarios are shown in Fig. 4.

Fig. 3.

Flowchart of network selection and service migration.

Fig. 4.

Vehicles with multiple types of communication devices.

In Fig. 4 it is observed that there are single-homed vehicles with single network technology radios like WAVE or UMTS and there are multi-homed vehicles that contain both the network technology capabilities. The cost of the communication and LDCAMS migration from one vehicle to another vehicle depends upon the types of vehicles taking part in communication. Ultimately, the CACENSA algorithm ensures cooperative and cost-effective network selection for reliable LDCAMS communication.

3.1.6. Context manager

Vehicles on the road gather context information continuously through the context monitor that forwards the information to the context manager. The context manager validates the information and stores it. This information provides the basis for the communication manager to ensure the service acts accordingly.

3.1.7. Service adaptation manager

The service adaptation manager is responsible to perform service adaptation when the communication manager triggers service adaptation. Adaptations define the behavior of services under different circumstances. e.g. how to perform in a highly congested environment or resource-constrained environment etc.

3.1.8. Handoff manager

The handoff manager is the module that is responsible for performing handoff among different available network devices. It performs this handoff on the basis of policy defined by the communication manager.

3.1.9. Session manager

The session manager performs the management of session for service communications. When a service needs to migrate from one node to another node, the session manager ensures the migration of state information of the service along with service code.

3.1.10. Resource monitor

The resource monitor monitors the currently available resources like location, speed, network-availability, etc.

3.1.11. Resource level agreements

As different nodes communicate and use each other’s resources, so before use, they must reach resource level agreements. These resources level agreements also provide the basis for service migration decisions. Collectively, there are numerous modules presented that participate in LDCAMS deployment, particularly in unplanned areas.

Another interesting aspect that the proposed LDCAMS architecture presents, is, its code size and complexity. The code has to be executed and stored in the vehicle. Thus, a vehicle’s capability to execute the code affects the overall system performance. Although there are several approaches to design and develop LDCAMS, however, this dissertation assumes LDCAMS is designed using the Smart Message Platform. Furthermore, the Smart Message Platform is based on the Java Virtual Machine. Literature shows in exemplary scenario (TJam: taken from [36]) that heap size for running the JVM and a small LDCAMS (TJam) is 172 Kb; however, vehicles are going to be providing a diverse range of application including JVM-based entertainment applications, therefore, the heap size may range from 16 MB to 512 MB. To cope with requirements raised by such applications, It is also evident from literature that automotive industry has agreed to equip vehicles with rich computation and communicational resources [3,20,22]. However, management of network traffic introduced by such applications in a cost-effective way is a challenge. This research work contributes CACENSA-based algorithm to support LDCAMS migration over an integrated network. The next section of this paper presents the implementation in NS-Miracle, naming the newer version as NS-Miracle-V, to validate the performance gain by CACENSA.

Main()

Start

Action=Calls(Proc Syscheck(), 10)

# calls syscheck procedure periodically in every t seconds

Switch (action)

Case (Fine):

Exit()

Case(Bad):

Calls (Take(NextNodeID), CheckNetworkstatus (Next NodeID)

#claim.checkstatus(ifid)

If Networkstatus =fine # the next host has similar network capability

Calls(Migrate(NextnodeID)

Else

update=Calls

(CLAIM.Handovermanager.interfacemanager.setupifid())

#Network #switches #to alternate supporting network interface i.e. UMTS

if update=1 then #if success in setting up new interfaceid

Calls(Migrate(NextnodeID)

#start migratingservice to new host

Else Goto 8

Proc Migrate(NN)

Start

While claim.detectnf(t)=false #check WAVE network in every t seconds

Continue data transfer / service migration

If claim.detectnf(WAVE)=true then

Calls(networkswitch(UMTS))

End

Goto 1

End

However, as this research is focused to present the LDCAMS migration using the cooperative & cost-effective network selection algorithm, LDCAMS communication is not considered further. To present and prove the efficacy of the algorithm network traffic modeling was required. It is presented in the next section.

3.2. Network traffic modeling

LDCAMS successful deployment on VANETs using the presented system design majorly depends upon two factors:

LDCAMS communication

LDCAMS migration

data using UMTS offering a data rate of 384 Kbps with the actual time taken for the transfer of the same over UMTS offering the data rate of 384 Kbps. The number of vehicles is assumed to be 150 and medium mobility is considered to perform the simulations. The second section of these simulations is performed to show more reliable LDCAMS communication and migration over the integrated network. The different sizes of data units used for simulations are shown in the following Table 1.

Table 1
File sizes

10 KB 50 KB 250 KB 1250 KB 6250 KB 31250 KB 156250 KB

4. Results and discussion

The results are shown in Fig. 5 and Fig. 6. It can be seen that with increasing file size, the time taken to transfer the file increases. In addition, it can be seen that the actual time taken for transferring a file is higher than the ideal time that the file should have taken. This is due to packet loss that occurs due to channel contentions as well as several other reasons. This packet loss has already been shown in the previous set of simulations.

Fig. 5.

Migration time vs. small to medium file size.

Fig. 6.

Migration time vs. medium to large file size.

The results show that when the number of vehicles in communication increases, packet loss increases as well. Hence, the total time for the migration of LDCAMS takes more time than the ideal time. Furthermore, due to the number of disconnections and packet losses, the network performance degrades. In such a situation, the absence of a supporting network will brings the system to a failed state. The use of the UMTS network as a supporting network is presented in this research. For this purpose, a cost-effective algorithm has also been employed. The performance comparison and discussion on the efficacy of the cooperative and cost-effective algorithm is conducted. This simulation is performed using the parameters presented in Table 2.

Table 2

Scenario parameters for measuring service migration time

Mobility: Medium at 40–60 km/h

Traffic: CBR

Data rate: WAVE at 2 Mbps, UMTS at 384 Kbps

Model [adapted to show unplanned areas]

Area: 1000 × 1000 m

Routing Protocol: AODV

Nodes and Data Sources: 150 Nodes

Networks: Single Home and Multihomes

Application Size: 10 KB to 156250 KB

This research addresses the network volatility leading to network failure of WAVE by providing a supporting network i.e. UMTS. A WAVE-based network may fail due to several reasons:

The WAVE network becomes unavailable due to communicating nodes becoming distant from each other (out of communication range), thus causing network failure;

WAVE network underperforms significantly due to network congestion and is considered as network failure.

To overcome these issues, network failure is assumed to occur at several points during LDCAMS migration. These network failure points (NFP) are define as the percentage of application traffic transferred from source to destination. For example, network failure may occur while 20% of application traffic was transferred from source to destination. To overcome these issues, network failure is assumed to occur at several points during LDCAMS migration. These network failure points (NFP) are define as the percentage of application traffic transferred from source to destination. For example, network failure may occur while 20% of application traffic was transferred from source to the destination node. Thus, it makes the network failure point as 20% of the total application file size. This research assumes a NFP will trigger Network switch (N/S) to supporting network i.e. UMTS. The simulations also create such network failures by introducing raw traffic to create network congestion. These types of network failures are also created ranging from 20% to 80% file size. These network failures lead to N/S to the supporting network.

The graphs shown in Figs 7–13 show the transfer of 10 KB to 156250 KB file as LDCAMS communication or LDCAMS migration. It can be seen that if the network becomes congested at a point where 20% of the file or LDCAMS has been migrated, it will take more time to complete the migration than if the network switching took place later on during communication. The reason for this result is that the data rate offered by UMTS is less than that of WAVE. Hence, the earlier the network switches from WAVE to UMTS, the higher the cost in time.

Fig. 7.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 10 KB.

Fig. 8.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 50 KB.

Fig. 9.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 250 KB.

Fig. 10.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 1250 KB.

Fig. 11.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 6250 KB.

Fig. 12.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 31250 KB.

Fig. 13.

Total migration time vs. network switch percentage from WAVE to UMTS: file size 156250 KB.

It is evident that although the network selection from WAVE to UMTS increases the cost of communication and LDCAMS migration, it adds reliability. It is important to as areas with security issues that requires continuous monitoring.

4.1. LDCAMS communication and migration

Performance of WAVE, UMTS, and CACENSA is presented in this section. These simulations are shown in two parts. Part-1 shows small to medium size file i.e. 10 KB to 1250 KB whereas the part 2 of these simulations shows the results of medium to large file sizes i.e. 1250 KB to 156250 KB. The performance is measured in terms of time required to migrate LDCAMS. Moreover, for CACENSA, exactly one switch i.e. from WAVE to UMTS is assumed. The graphs shown in Figs 14–17 show the LDCAMS communication or LDCAMS migration as transfer of 10 KB to 1250 KB size files with single network switching point at 20%, 40%, 60%, and 80% respectively. It can be seen that WAVE takes a minimum amount of time if it is used for complete LDCAMS migration. However, in unplanned areas, there are many chances that WAVE becomes unavailable or degrades in performance to support the LDCAMS migration. It is noted that UMTS takes a greater amount of time than WAVE. This is due to higher data rate offered by WAVE. When the performance of UMTS is compared with CACENSA, it can be seen that UMTS performs better for smaller file sizes such as 10 KB to 1250 KB. This is because additional time of network selection and switching is added to the CACENSA-based LDCAMS migration time. When the file size increases over approx. 300 KB, it is evident that CACENSA outclasses UMTS. For larger files, CACENSA performs better than UMTS in terms of cost as well as time

Fig. 14.

Comparison of WAVE, UMTS and CACENSA in small to medium size file with N/S at 20%.

Fig. 15.

Comparison of WAVE, UMTS and CACENSA in small to medium size file with N/S at 40%.

It is also seen that whenever WAVE is available, it performs better than UMTS and CACENSA. It is also evident that CACENSA time decreases if the network switching takes place at later stage.

Fig. 16.

Comparison of WAVE, UMTS and CACENSA in small to medium size file with N/S at 60%.

Fig. 17.

Comparison of WAVE, UMTS and CACENSA in small to medium size file with N/S at 80%.

The graphs shown in Figs 18–21 show the LDCAMS communication or LDCAMS migration as transfer of 1250 KB to 156250 KB size files with single network switching point at 20%, 40%, 60%, and 80% respectively. It can be seen that WAVE shows a similar pattern and takes the minimum amount of time to complete LDCAMS migration. However, in unplanned areas there are many chances that WAVE becomes unavailable or degrades in performance to support LDCAMS migration. Moreover, is evident that UMTS takes a greater amount of time than WAVE. This is due to the higher data rate offered by WAVE. For medium to large file size communication and migration, when the performance of UMTS is compared with CACENSA, it can be seen that CACENSA performs better than UMTS. For larger files, CACENSA performs better than UMTS in terms of cost as well as time. However, it is also seen that whenever WAVE is available, it performs better than UMTS and CACENSA. It is also evident that CACENSA time decreases if the network switching takes place at later stage.

Fig. 18.

Comparison of WAVE, UMTS and CACENSA in medium to large size file with N/S at 20%.

Fig. 19.

Comparison of WAVE, UMTS and CACENSA in medium to large size file with N/S at 40%.

Fig. 20.

Comparison of WAVE, UMTS and CACENSA in medium to large size file with N/S at 60%.

Fig. 21.

Comparison of WAVE, UMTS and CACENSA in medium to large size file with N/S at 80%.

Figures 14–21 clearly show that availability of a supporting network assists to provide reliability and continued service availability in unplanned areas. LDCAMS Communication and Migration Comparison using WAVE (with additional applications traffic), UMTS and CACENSA. This section presents the results of simulations performed to compare performance of WAVE and UMTS networks offering data rate of 2 Mbps and 384 Kbps, respectively, with CACENSA-based integrated network to support LDCAMS migration. In realistic scenarios, there are several non-safety applications assumed to run over the WAVE network. Thus, the extra network traffic generated by these applications limits the available bandwidth for LDCAMS. These simulations are performed considering the parameters presented in Table 3.

Table 3

Scenario parameters for measuring service migration time with additional application traffic

Mobility: Medium at 40–60 km/h

Traffic: CBR

Data rate: WAVE at 2 Mbps, UMTS at 384 Kbps

Mobility Model: Manhattan Mobility Model [adapted to show unplanned areas]

Area: 1000 × 1000 m

Routing Protocol: AODV

Nodes and Data Sources: 150 Nodes

Networks: Single Homed and Multihomed

Application Size: 250 KB to 156250 KB

The major difference of these scenarios from those previously presented is to consider multiple network traffic flows generated by other VANET applications over WAVE.

The graph shown in Fig. 22–25 shows the LDCAMS migration as transfer of 250 KB to 156250 KB size files with single network switching point at 20%, 40%, 60%, and 80%, respectively. This scenario particularly considers extra traffic generated by several other non-safety applications. The additional traffic limits the available bandwidth for LDCAMS migration, thus the performance of the WAVE network degrades.

The performance of such a network is compared with a CACENSA-based network. A CACENSA-based network considers switching the network to UMTS at different points during the migration and shows a better performance than WAVE to support LDCAMS migration. However, it may be noted that UMTS may perform even better in terms of time under certain circumstances; however, due to cost involved for using UMTS, it is important to perform cost-effective network selection for LDCAMS migration, thus, only when WAVE underperforms or is unavailable, should UMTS be considered to support LDCAMS migration.

Fig. 22.

Comparison of WAVE (with additional network traffic), UMTS and CACENSA with N/S at 20%.

Fig. 23.

Comparison of WAVE (with additional network traffic), UMTS and CACENSA with N/S at 40%.

Fig. 24.

Comparison of WAVE (with additional network traffic), UMTS and CACENSA with N/S at 60%.

It can be seen from the graphs presented that in case of network failure at any point during LDCAMS migration, supporting network assists to provide continuity for completion of service migration.

Fig. 25.

Comparison of WAVE (with additional network traffic), UMTS and CACENSA with N/S at 80%.

Furthermore, while WAVE’s performance degrades significantly during congestion, network switch to UMTS improves the performance by minimizing the migration time by 13% to 17%. Choice of UMTS may be considered as an option for complete migration of LDCAMS; however, it is not cost-effective approach.

The results presented in this section demonstrates the effectiveness of CACENSA for LDCAMS migration. The graphs contribute to establish the facts as follows:

WAVE network is volatile and may underperform significantly or become unavailable during LDCAMS migration;

The supporting network, UMTS, helps to support continuous service migration in minimal time;

CACENSA contributes cost-effective network selection for LDCAMS migration.

Finally, the next section of simulations presents the number of failed attempts to complete LDCAMS migration due to network unavailability. This section presents the results of simulations performed to compare performance of WAVE and CACENSA in terms of number of failed attempts to migrate LDCAMS. These simulations are performed to record the number of failed attempts of LDCAMS. These failed attempts can be due to any of the following reasons:

The WAVE network not available at destination node;

The destination node crashes/becomes out of reach for unlimited time;

Failure due to network congestion of WAVE-based network.

Figure 26 presents the results of simulations to evaluate WAVE-based network and CACENSA. The results show that migrating LDCAMS over the WAVE-based network, particularly in unplanned areas, where the distribution of vehicular traffic can be uneven to a large extent. The uneven vehicular traffic produces not only uneven network traffic but also a network node distributions that is characterized by network disconnections. In addition, such node distributions may cause nodes unavailable to each other for any communication.

Fig. 26.

NFA comparison of WAVE and CACENSA with different file sizes.

The results presented in this figure demonstrates the higher number of failed attempts for WAVE-based network.

4.2. Application prototype

To evaluate the efficacy of our simulations, we further designed file migration application using Android platform. The application has the capability to start file migration transfer using preferred network and record the transfer time. Using this application we tried to transfer video and audio files with multiple points where the network was switched from 3G to WiFi (802.11).These simulations are performed considering the parameters presented in Table 4. Results observed are shown in Fig. 27. It can be seen that file transfer throughout prototype taking more time than shown by simulations. The results can be justified as 802. Wifi signals on the road used were having variations. Signal noise might have also degraded the performance accordingly.

Table 4
Scenario parameters for measuring service migration time

Mobility: Medium at 40–60 km/h

Traffic: CBR

Data rate: WAVE at 2 Mbps

Mobility Model: Manhattan Mobility Model[adapted to show unplanned areas]

Area: 1000 × 1000 m

Routing Protocol: AODV

Nodes and Data Sources: 150 Nodes

Networks: Single Homed and Multihomed

Application Size: 250 KB to 156250 KB

Fig. 27.

Comparison of file transfer time (prototype vs. simulation).

In addition there were multiple disconnections in the network were observed while we were commuting on the roads. The peer application nodes were hosted on multiple cars and variable traffic sources were also generated to create scenario as real as possible. The results were averaged after multiple attempts to transfer file keeping the confidence interval at 95%. We also assume and observed variable data rates available while we were using 3G.

4.3. Application size vs. cost

Another direction to improve performance is that if WAVE is showing degraded performance or is unavailable in vehicles and UMTS has been selected for the complete LDCAMS migration, then LDCAMS migration should be completed using UMTS. This would increase the cost; however, the network traffic may be reduced by not starting the migration repeatedly. Here the cost function is simply shown as follows: $\begin{array}{l} C (I) = μ_{t} f_{t} (I) + μ_{m} f_{m} (I) \\ for I \in {WAVE, UMTS} . \end{array}$ In the given function, $f_{t} (I)$ and $f_{m} (I)$ denotes the variables for data rate and monetary cost in network I, respectively. In $(I)$ , $μ_{t}$ and $μ_{m}$ denotes the weight of each factor, which are set according to user preferences.

The constraint pertaining to $μ_{t}$ and $μ_{m}$ is given by $\begin{array}{l} μ_{t} + μ_{m} = 1 \\ Network I improves with \\ lower values of C (I) . \end{array}$

5. Conclusion

Successful deployment of services, particularly location-dependent, context-aware migratory services (LDCAMS) over VANETs largely rely on the performance of the underlying network. The major contribution of this research falls in this area. It discussed the use of WAVE as the only available network, and concluded that it is not able to meet the challenges for communication and service migration due to the intermittent nature of network connectivity. Secondly, the choice of using UMTS as an underlying network cannot be fully entertained due to its capacity limitations and the cost to use the UMTS network. Finally, this research paper discussed provision of UMTS as additional network support for LDCAMS migration. However, this integrated approach to support LDCAMS deployment requires an efficient algorithm for triggering hand-offs between the WAVE network and the UMTS network to provide efficient and cost-effective, context-aware service migration performance in an unplanned geographical area. For such integration, we presented how the two networks, i.e. WAVE and UMTS, can be integrated into a single operational unit. Furthermore, a comprehensive system design is presented to show how LDCAMS can be hosted and migrated from one node to another.

To evaluate the performance of the underlying integrated network, several amendments were made to NS-Miracle, resulting in NS-Miracle-V. A series of simulations are presented to provide evidence that in the presence of a backup supporting network, LDCAMS communication and migration is more reliable. For this purpose, a simple algorithm CACENSA is implemented, and its performance is compared with the performance of WAVE and UMTS alone. The performance comparison shows that depending upon the size of LDCAMS and network switching time.

10% to 20% improvement in terms of time required to transfer LDCAMS from source to destination along with management data in the presence of additional network traffic on the WAVE network. It is important to consider that additional network (UMTS) charges for use. The analysis of results shows in further complex scenarios where WAVE’s performance degrades considerably, the UMTS network support can improve the system reliability as well as minimize the time required for LDCAMS migration. The performance gain of the CACENSA algorithm can be improved if UMTS provides 2 Mbps; however, as in developing countries, the usual data rate offered is 384 kbps, and thus up to 20% performance gain can be achieved.

5.1. Contributions

The contributions in this research are as follows:

Comprehensive system design is presented to deploy LDCAMS in unplanned areas;

To deploy LDCAMS in unplanned areas, additional network support (i.e. UMTS) is proposed;

A cooperative and cost-effective network selection algorithm is presented;

Several amendments are made to the Manhattan Mobility Model to reflect unplanned areas;

NS-Miracle is adapted to NS-Miracle-V (with IEEE802.11p WAVE support) for simulating VANET scenarios with more than single network connectivity.

5.2. Open issues

Several open challenges and issues need to be addressed in order to provide reliable LDCAMS deployment. All the results presented in this research are based on the simulations performed. A Real Test Bed (RTB) is missing in this research so that real experiments may be performed and results can be compared with the simulation results to validate the effectiveness of this research.

Currently network simulations are performed and Network failures are created by design. One important direction is to explore how dynamic network events affect the performance of CACENSA.

A priority mechanism for LDCAMS needs to be employed if there are more than one types of LDCAMS priority, affecting how CACENSA will compute and select the underlying network.

A real time prototype is required to see how code migration and execution migration performs under a volatile network and under a CACENSA-based network.

5.3. Future work

A very practical future direction is to investigate the possibility of educating the public with respect to their driving behaviour by monitoring road traffic using public vehicles. Such a system could also be used to identify misbehaving vehicles, and those that cause unpleasant events on the road.

To evaluate the performance of LDCAMS in unplanned areas supported by CACENSA, a prototype needs to be engineered. Furthermore, results gathered through this prototype need to be compared with simulation results presented in this research paper.

Decision making process for code offloading/service migration can largely impact the system’s performance. Thus, an important future work shall be to evaluate system’s performance against different decisions made in different scenarios.

References

www.vehicle-infrastructure.org, 2011.

Abrougui, Design and performance evaluation of service discovery protocols for vehicular networks, Ottawa-Carleton Institution for Computer Science, Faculty of Graduate and Postdoctoral Studies, 2011.

Boagey and

Slusser, New functionalities, new risks: It’s time to secure the connected car, Automotive Megatrends Q2 (2015).

Brignolo, The SAFESPOT integrated project – Co-operative systems for road safety, in: TRA Conference 2006, Goteborg.

T. CAMP, Vehicle Safety Communications Project: Identify intelligent vehicle safety applications enabled by DSRC, CAMP 39255 Country Club Drive, Suite B-30, Farmington Hills, MI 48331, 2005.

Car2Car Communication Consortium, 2000 [Feb 2014; available from: www.car-to-car.org].

Civera, Wireless sensors network for intelligent transportation systems, in: IEEE 69th Vehicular Technology Conference: VTC 2009 Spring, Barcelona, Spain, 2009.

Dahiya and

R.K.

Chauhan, A comparative study of MANET and VANET, Environment Journal of Computing 2(7) (2010).

Eom,

Figueiredo,

Cai,

Zhang and

Huang, MALMOS: Machine learning-based mobile offloading scheduler with online training, in: 2015 3rd IEEE International Conference on Mobile Cloud Computing, Services, and Engineering (MobileCloud), 2015, pp. 51–60. doi:10.1109/MobileCloud.2015.19.

10.

Feiri,

Petit and

Kargl, The impact of security on cooperative awareness in VANET, in: Vehicular Networking Conference (VNC), IEEE, 2014.

11.

Festag, “NoW – Network on Wheels”: Project objectives, technology and achievements, in: 6th International Workshop on Intelligent Transportation (WIT), Hamburg, Germany, 2008.

12.

Fiore, Discovery and verification of neighbor positions in mobile ad hoc networks, IEEE Transactions on Mobile Computing 12(2) (2013), 289–303.

13.

FleetNet project – Internet on the road, 2000 [available from: http://www.et2.tu-harburg.de/fleetnet2000].

14.

Flores and

Srirama, Adaptive code offloading for mobile cloud applications: Exploiting fuzzy sets and evidence-based learning, in: Proceeding of the Fourth ACM Workshop on Mobile Cloud Computing and Services, Taipei, Taiwan, 2013.

15.

Giurgiu,

Riva and

Alonso, Dynamic software deployment from clouds to mobile devices, in: Proceedings of the 13th International Middleware Conference, Montreal, QC, Canada, 2012.

16.

Hartenstein,

Bochow and

Ebner, Position-aware ad hoc wireless networks for inter-vehicle communications: The Fleetnet project, in: MobiHoc ’01: Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking & Computing, Long Beach, CA, USA, 2001.

17.

Hartman and

Strasser, Saving lives through advanced vehicle safety technology, Intelligent Vehicle Initiative Final Report 2005 [Feb 2014, available from: http://ntl.bts.gov/lib/jpodocs/repts_pr/14153_files/ivi.pdf].

18.

Hartman and

Strasser, Saving lives through advance vehicle safety technology, Intelligent Vehicle Initiative Final Report, 2005.

19.

M.A.

Hassan,

Bhattarai,

Wei and

Chen, POMAC: Properly offloading mobile applications to clouds, in: Proceedings of the 6th USENIX Conference on Hot Topics in Cloud Computing, Philadelphia, PA, USA, 2014.

20.

Jayaraman, Connected cars in connected era, Automotive Megatrends Q2 (2015).

21.

Khairy,

H.H.

Ammar and

Bahgat, Smartphone energizer: Extending smartphone’s battery life with smart offloading, in: 2013 9th International Wireless Communications and Mobile Computing Conference (IWCMC), 2013, pp. 329–336. doi:10.1109/IWCMC.2013.6583581.

22.

Kinder, Cost effective updates of automotive software, Automotive Megatrends Q2 (2015).

23.

Knorr, Reducing traffic jams via VANETs, Transactions on Vehicular Technology 61(8) (2012), 3490–3498.

24.

Kosta,

Aucinas,

Pan,

Mortier and

Xinwen, ThinkAir: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading, in: INFOCOM, 2012 Proceedings, IEEE, 2012, pp. 945–953. doi:10.1109/INFCOM.2012.6195845.

25.

Laganà, Secure communication in vehicular networks – PRESERVE demo, in: Proceedings of the 5th IEEE International Symposium on Wireless Vehicular Communications, IEEE, 2013.

26.

Lee

et al., Dissemination and harvesting of urban data using vehicular sensing platforms, IEEE Transactions on Vehicular Technology 58(2) (2009), 882–901. doi:10.1109/TVT.2008.925303.

27.

Y.-H.

Lee

et al., An efficient geo-aware peer-to-peer resource discovery and sharing scheme in vehicular ad-hoc networks, in: Ninth International Conference on Information Technology – New Generations, 2012.

28.

Mäkinen, DRIVE C2X methodology framework, in: DRIVE C2X, 2011.

29.

Meincke, Wireless adhoc networks for inter vehicle communication, in: Zukunft der Netze – Die Verlezbarkeit meistern, 16. DFN-Arbeitstagung über Kommunikationsnetze, 2002, pp. 233–245.

30.

Morgan, Notes on DSRC & WAVE Standards Suite: Its Architecture, Design, and Characteristics Communications Surveys & Tutorials, IEEE, 2010, pp. 504–518.

31.

V.J.

Patel and

A.P.

Gharge, A review on routing overhead in broadcast based protocol on VANET, International Journal of Engineering and Innovative Technology (IJEIT) 2(5) (2012).

32.

Pauty

et al., Research challenges in mobile and, context-aware service development, in: Future Research Challenges in Software and Services (FRCSS 06), Vienna, Austria, 2006.

33.

PostNote, ICT in developing countries, 2006.

34.

Riva, Middleware for mobile sensing applications in urban environments, Department of Computer Science Series of Publications, University of Helsinki, Helsinki, Finland, 2007.

35.

Riva,

Nadeem,

Borcea and

Iftode, Context-aware migratory services in ad hoc networks, IEEE Transactions on Mobile Computing 6(12) (2007), 1313–1328. doi:10.1109/TMC.2007.1053.

36.

Riva,

Nzouont and

Borcea, Context-aware fault tolerance in migratory services, in: MobiQuitous 2008, Dublin, Ireland, ACM, 2008.

37.

Ul-Amin, Cooperative & cost-effective network selection: A novel approach to support location-dependent & context-aware service migration in VANETs, PhD thesis, University of Glasgow, UK, 2015.

38.

Webpage. http://www.3gpp.org/Technologies/Keywords-Acronyms/article/umts.

39.

Webpage. Gunmen shoot Sri Lanka cricketers, 2009 [available from: http://news.bbc.co.uk/2/hi/south_asia/7920260.stm].

40.

Weiß, Integrating value-added services: Connected mobile life. Safe and Intelligent Mobility, 2013 [available from: http://simtd.de/index.dhtml/enEN/Vision/Integration_Mehrwertdienste.html].

41.

Wu and

Zitterbart, Service awareness and its challenges in mobile ad hoc networks, in: Workshop der Informatik 2001: Mobile Communication over Wireless LAN: Research and Applications, 2001.

42.

Yan, Cooperative collision warning through mobility and probability prediction, in: 2010 IEEE Intelligent Vehicles Symposium, San Diego, CA, USA, 2010, pp. 1172–1177.

43.

Yang and

Bagrodia, Evaluation of VANET-based advanced intelligent transportation systems, in: VANET’09, Beijing, China, 2009.

44.

Yavwa and

Kritzinger, Enabling communication in developing regions, EJISDC 6 (2001), 1–15.

45.

Zeadally

et al., Vehicular ad hoc networks (VANETS): Status, results, and challenges, Telecommunication Systems 50(4) (2012), 217–241. doi:10.1007/s11235-010-9400-5.