Integrated Extensible Simulation Platform for Vehicular Sensor Networks in Smart Cities

3.1. Design Objectives

From the perspective of applications, main tasks of VSNs are data collection, data management, transmission control, and finally providing timely and reliable services for smart traffic. In this way, VSN can be considered as a mobile network of massive distributed heterogeneous data. The difficulties to design VSN simulator are complex scenario setting, various data representation, and flexible control mechanisms. In short, we list several objectives in the following for our platform to satisfy. (1)

Support complex traffic scenario construction, with well-managed hierarchy of traffic participants and fine scenario regulations.

3.2. System Framework

In smart cities, as the basic unit, data cell has its life cycle, from data generation to data processing, then to data usage, until data death [30]. From data life cycle standpoint, we design the system framework of our simulator. First of all, we need an actual urban traffic scenario to support environment for data growing. We name this basis as scenario construction module. In data generation process, we use portable and stable sensors to collect information, so we set data collection layer at the bottom of the architecture. Besides, for specific rules about data formats and generation patterns required to guarantee expected data generation, the second lowest layer is data management layer, including data representation and data generation. After data generation, in order to successfully transmit data from one vehicle to another, vehicular transmission control mechanisms strictly influence data processing, including data storage, data transfer, and data update. Thus, this layer is named transmission control layer. When the data reaches its destination, it must be resolved and analyzed according to the requirements of a specific smart service, in order to provide appropriate data for the ultimate use. We name this layer smart service layer. Finally, the target terminal utilizes the data and decides on whether to delete or keep it, which is named terminal application layer. To sum up the previous analysis, VSN system can be segmented into five layers, data collection layer, data management layer, transmission control layer, smart service layer, and terminal application layer, as shown in Figure 1.

OPEN IN VIEWER

Figure 1

System framework.

In BHU-VSim, we design a hierarchical object structure to construct scenarios with fast-moving vehicles, slow-moving pedestrians, static roadside infrastructure, and other entities. In data collection layer, sensors equipped on vehicles, roadside infrastructures, and mobile devices with pedestrians gather surrounding information. In data management layer, various data representation and flexible data generation are discussed. Transmission control layer contains task scheduling, storage management, and routing deployment components. Smart service layer supports basic VSNs' services, such as safe driving and traffic management. The top layer is terminal application layer, which satisfies different requirements of different terminals. Besides scenario setting and performance evaluation, our research mainly covers the data management, transmission control and smart service layers. In our platform, we focus on four modules as listed in the following. (1)

Scenario construction: to construct vehicular network scenarios, we introduce the digital map pattern to load instance map, and manage entities in a hierarchical structure to support flexible entity loading. Each entity has its characteristics and can adjust its movement states.

To be noted, service optimization is used to prepare rough data well for terminal applications. Via computing service parameters which serve for the applications and defining optimization methods to optimize the simulation results of service parameters, this module ultimately realizes the value of data and provides high-quality service. Here, we see service optimization module always has strong association with specific applications. For an instance, a multimedia resource sharing application may require selection and integration of different data blocks, while a traffic monitoring application maybe needs the latest vehicular flow rate at each waypoint. Different requirements lead to a huge difference between the implementations of service optimization modules in these two applications. Therefore, to introduce general models in our simulator, we omit further discussion about service optimization in the next sections. However, an instance of service optimization module will be depicted in Section 7. In Sections 4–6, we describe core issues in the implementation of scenario construction, data management, and transmission control modules in detail.

4.1. Map Format

To simulate transportation in smart cities, we focus on the road information in the urban map rather than buildings, farmland, and so forth. Thus, each map is composed of many paths, and each path has a list of road waypoints. Similar with ONE, we select  .wkt digital map file to be the standard map formats. To better simulate roads in cities, we add multilane and directions for  .wkt file. Specifically, we allow users to set the numbers of lanes in two directions in the map file. Default numbers of lanes in two directions are both 1. The direction in line with the order of road waypoints is named positive direction, remarked “+.” The other direction is called negative direction, remarked “−.” The serial number of each lane is started from the roadside (1) to the middle of the path (n). Each lane has its lane number, such as “+1” and “−2.” To be noted, real city maps in  .wkt format can be imported into the system directly.

4.2. Entity Management

To support unified and extensible traffic entity management, we propose a hierarchical entity structure. Entities with similar characteristics comprise one group with the common attributes, and similar groups are also clustered together, in order for convenient management and deployment. The system automatically constructs entity groups in batch and then regulates entities with special features different from its group. Each entity has three kinds of attributes, including basic attributes (ID,name,count, etc.), mobility attributes (mobilityModel, initialLocation, path, speed, waitTime, movingTime, etc.), and communication attributes (commRange, dataRate, bufferSize, router, packages, etc.). Users can customize these attributes for a particular application in the class file Entity.

BHU-VSim is embedded with several movement models for traffic participants, such as CarMovementModel and BusMovementModel. To improve flexibility of the platform, external movement models are supported by extending MobilityModel class and overriding at least two methods setInitialLocation() and setPath(). Additionally, actual mobility files can be used in the system by calling methods with parameter mobilityFile.

Besides, in BHU-VSim, we implement IDM car-following model [31] and MOBIL lane-changing model [32] to simulate vehicular mobility constraints. With configuration sentences carFollowingModel = IDM and laneChangingModel = MOBIL in the mobility attributes, users can use these models.

4.3. Traffic Status Adjustment

To improve realness of BHU-VSim, we use traffic status adjustments to set jams in the scenario. We propose the configuration of influence sphere to improve the simulation accuracy, compared with obstacles defined in ASH [15]. For instance, a traffic control measure may just stop private cars passing at one direction. Relevant methods to set a block are shown in Table 1. Among the methods, setPaths() and setEntities() are required. The default lanes are all lanes, and the default speed is 0.

OPEN IN VIEWER

Table 1

Interface methods to set a block.

Usage	Class	Method	Parameter
		setPaths()	Path [ ] p
Calling	Block	setLane()	Lane [ ] ln
		setEntities()	Groups [ ]   entities
		setSpeedRange()	Float lowSpeed  Float highSpeed
Associating	Scenario	addBlock()	Block b

The scenario construction module of BHU-VSim supports urban map with multilane paths, has a hierarchical structure to manage transportation participants, and also allows setting road blocks. Although these specialties help to construct more real traffic scenario, there are still many problems to be solved, such as the traffic light model, the overlapping issue due to overpass, and the building's interference with V2V communication. More actual 3D model may be helpful to overcome these problems in the future.

5.1. Data Representation

To improve the flexibility and availability of BHU-VSim, we design a general data container to present and differentiate various data. We partition a package into header section and data section. For a specific application, the data package can be defined by inheriting class DataPackage, setting necessary attributes, and overriding the method Entity.createPackage() to assign values for the attributes in the package.

In our simulator, we have designed three kinds of data packages for typical services in VSNs, entity status data, digital data, and multimedia data. Entity status data presents this entity's basic information, moving state, and position relations with others, in order to monitor traffic and support safe driving. Digital data is always taken from different kinds of sensors to record temperature, humidity, and so forth. These sensors use digital to indicate the traffic states and road states. Multimedia data is designed for entertainment applications, including file format, minimum data rate, recovery rate, and content.

Besides data messages, control messages are required in almost every application. They always have particular requirements about transmission and analysis. Thus, we leave the discussions about control messages for our future work.

5.2. Package Generation

In BHU-VSim, we provide two interfaces to periodically or randomly generate data packages. By calling the method setProdPkgGntTime(float start, float end, float interval), this entity will generate one data package every interval rounds from the round start to end. By calling methods setRandPkgGntTime(float start, float end, int count), this entity will randomly generate count data packages from start to end. Although these methods are not complete, they are sufficient for usual data generation.

In BHU-VSim, we define the format of data package and present three typical instances. Besides, two data generation methods enrich the simulation scope. In this module, there are much more research needed on the control package formats and simplified data structure design, in order to improve the accuracy and efficiency of the simulation.

6.1. Task Scheduling

To provide equal chance for each entity to transfer data, we propose random entity selection policy to select one meeting entity to send data first. Then, we use scheduling model to compute the transmission priority of each package in the sender entity, to improve the transmission efficiency.

Using the random entity selection policy, each meeting entity generates a random value in the interval (0, 1). Then, the entity with the largest value transfers first, and the entity having the second largest value transfers next, until each of them transfers one package. If there is still a transfer chance, the second round of transmission with the same sequence takes place. In this way, each entity has an equal chance to send data. Here we assume that all the nodes obey this policy, without mendacity. How to realize this assumption is left for research on network security.

When one entity has a chance to transmit data, firstly it computes scheduling priorities of all the packages in its storage and then selects the package having the highest priority to transfer. Here, we use basic scheduling attributes to stand for those attributes defined in the ScheduleModel class. The method computePriority() in this class uses the values of these attributes to compute the scheduling priority.

The customized scheduling model should inherit from the class ScheduleModel, setting basic scheduling parameters and overriding the computePriority() method.

Traffic entities use the method setScheduleModel() to set scheduling model for their packages and assign values to basic scheduling attributes in the model. Here, we suggest the configuration to be set in batch if one or more groups of entities have the same policy.

6.2. Storage Management

Taking VSN as a distributed storage system with limited storage space in each vehicle, when the buffer is overfilled, the vehicle drops data according to package dropping rule, in order to make space for new coming data.

To increase the flexibility of BHU-VSim, we design a package dropping model based on selected attributes. The implementation is similar to the task scheduling policy. Basic dropping attributes are defined in the DropModel class, and the method computePriority() uses the values of these attributes to compute the dropping priority. Packages with higher priorities are dropped earlier. Traffic entities use the method setDropModel()to set drop model for their packages.

6.3. Routing Deployment

In urban traffic, each entity has its routing protocol to transfer data packages. For instance, the fast-moving vehicle may use Prophet protocol to transfer data to a specific destination, while road-side infrastructure may flood data to passing buses. Furthermore, to satisfy complicated requirements, we support flexible deployment according to traffic states. For example, in a crowded area, vehicles use Spray and Wait routing protocol to keep the number of package replica within a limit, while in some sparse area, Epidemic routing is selected to increase the probability of successful transmission. Thus, we support routing deployment based on different entity groups and traffic states.

Here, traffic state attributes are those attributes of the entity, which affect it to select routing protocol. Each entity sets its routing protocol with the method setRouter() by considering the values of these traffic state attributes.

BHU-VSim has been integrated with several typical routing protocols, including EpidemicRouter, SprayWaitRouter, and ProphetRouter classes. The interface to import new routing protocols is also provided. We use basic routing attributes to stand for those attributes defined in a new routing class, and the method update() in the class uses the values of these attributes to make routing decision, such as whether to transmit this message and how many replica to transmit (the usage of the number of replica can be obtained from SprayWaitRouter class). Users can create a new Router class inheriting the BasicRouter class, define the basic routing attributes, and override the method update(), to implement customized routing decision making process.

Besides the control methods described previously, we have concrete operation process in the core of the platform. In other words, user-defined control mechanisms are well integrated into BHU-VSim, if they are configured using the interface methods as defined previously. Although our improvement has great significance to simulate actual applications in VSNs, there are still more problems about transmission control to be handled, such as data inconsistency, data corruption, and data acknowledgment. Besides, to simplify and clarify the structure of the simulator, we omit the handshake process when establishing connection. In our future work, we should gradually improve the fidelity of the transmission process.

7.1. An Instance: Real-Time Traffic Monitoring

As smart traffic is attracting more and more attentions from the government to individuals, we introduce one instance application, real-time traffic monitoring in VSNs, which aims to optimize vehicles' path selection to avoid traffic jams through V2V communication, without any roadside infrastructures.

In scenario construction module, to set urban traffic scenario for this application, we deploy two vehicle groups, VGroup1 and AGroup1, in the 500 × 500 map zone during the simulation rounds [ 0 , 500 ] . VGroup1 has 100 cars moving with CarMovementModel movement model, and AGroup1 has 12 buses with BusMovementModel mobility model. Here, buses in AGroup1 gather traffic congestion information, because of their stable movement paths, fixed departure interval, and high network coverage. Cars in VGroup1 just communicate with AGoup1 to get the traffic state. In this way, the traffic state can be disseminated in the scenario with low transmission overhead. Here, we use our traffic status adjustment method to set one jam on the shortest path from the start point to the destination point. Configuration interfaces are listed in Table 2.

OPEN IN VIEWER

Table 2

System configurations for the instance application.

Module	Function	Method	Remark
Scenario construction	Set mobility models for entities	VGroup1.setMobilityModel(Car-MovementModel) AGroup1.setMobilityModel(Bus-MovementModel)
	Set a traffic block b	b.setPaths(path1, path2)  b.setEntities(VGroup1, AGroup1)  b.setSpeedRange(0, 5) scenario.addBlock(b)
Data management	Represent data package p	AGroup1.createPackage()	Data: ID, location, velocity, and record time
	Set generation time of data package p	AGroup1.setProdPkgGntTime (0, 400, 5)
Transmission control	Set task scheduling policy ts	VGroup1.createScheduleModel(ts) AGroup1.createScheduleModel(ts) ts.computePriority()	Basic scheduling attributes: record time and location
	Set package dropping policy pd	VGroup1.createScheduleModel(pd) AGroup1.createScheduleModel(pd) pd.computePriority()	Basic dropping attributes: record time
	Set routing protocols for buses in AGroup1	AGroup1.setRouter()	Traffic state attributes: velocity

In data management module, we use the vehicle driving speed to indicate traffic congestion degree. Specifically, if the vehicle passing by one path runs fast, the traffic there is smooth and clear; if the vehicle can hardly move forward, there is possibly a traffic jam. In the implementation, we use entity status data to represent the data package. To save storage space, the entity status data just contains a quaternion, including recorder entity's ID, location, velocity, and record time. Concerning data generation pattern, each bus generates 1 package in every 5 rounds from the 0th round to the 400th round. Relevant methods are listed in Table 2.

In transmission control module, to improve transmission efficiency, we utilize task scheduling and package dropping policies. In the task scheduling policy, we use two attributes in data package p, record time and location, to be basic scheduling attributes. Packages with higher record time and more adjacent location are transferred earlier than others. In the package dropping policy, we use record time to be basic dropping attribute. Packages with lower record time are dropped earlier than others, to save space for new data. For the routing protocols, we use the embedded protocols EpidemicRouter and ProphetRouter. The velocity of entity is traffic state attribute. When the velocity is equal to or larger than 20, which means the traffic state is excellent, buses use EpidemicRouter to propagate information; otherwise, when the traffic is jammed, they use ProphetRouter to decrease transmission overhead. Table 2 shows the configuration methods.

To avoid transmitting traffic states of irrelevant paths, buses just collect data about the 5 recommended shortest paths. Cars obtain the traffic information when they communicate with buses. Then, cars can optimize their path selection by analyzing the traffic states.

In service optimization module, with geographical data and traffic data, we put forward the path selection method. To avoid traffic jams, cars exclude the initial recommended paths including jams first and then select the one with the shortest path as the final path. However, maybe all the initial paths have jams. In this case, another 5 short paths are computed, and another round of jam rejection is implemented, until one path excluding jams is found. The GUI of BHU-VSim is designed to show the scenario and transmission state, as presented in Figure 2(a). The result of path selection to avoid jams is shown in Figure 2(b).

OPEN IN VIEWER

Figure 2

GUI of the instance application.

For other applications, users just need to configure the scenario, define the data, and override relevant control methods, in order to provide required services. Overall, we can conclude that the simulation platform BHU-VSim is easily configurable and extensible. It can satisfy different requirements of various applications in VSNs.

7.2. Statistical Analysis

In our simulator, we have data analysis module to compare the statistic results of different algorithms. Independent of the traffic monitoring instance, we test the performance of typical routing protocols under limited storage in VSNs, including Epidemic, Prophet, and Spray and Wait routing protocols. Configurations are listed in Table 3. We set the shortest path map-based movement model and FIFO package dropping model for vehicles.

OPEN IN VIEWER

Table 3

Configurations for the example of statistical analysis.

Parameter	Value
Network area	5000 × 5000 m2
Number of vehicles	100
Simulation time	12 h (1 round stands for 1 second)
Communication radius	100 m
Mobility model	The shortest path map-based model
Mobility speed	Random in (10, 20) m/s
Data rate	2 Mbps
Size of data message	256 KB
Size of storage space	5 MB
Data generation	1 message every 15 min by each vehicle
Package dropping model	Fist in first out (FIFO)

The evaluating indicators are the delivery ratio (ratio of the number of successful delivery messages to the number of total messages), average delay (average delay of successful delivery messages), average hop (average hop of successful delivery messages), and average number of replicas (ratio of the number of total replicas to the number of messages). The simulation results are shown in Figure 3.

OPEN IN VIEWER

Figure 3

Statistic results of different routing protocols.

From Figure 3, we see that in general, Spray and Waitrouting protocol performs best among the three protocols. It has the highest delivery ratio, the lowest average delay, the lowest average hop, and the lowest average number of messages. The reasons lie in two parts. (1) As we use the shortest path map-based movement model, the advantages of Prophet cannot be shown out. This is because the mobility model causes irregular counter probabilities, which seriously interfere the forwarder selection in Prophet routing protocol. (2) The Epidemicrouting protocol uses flooding method to disseminate data, so it leads to heavy resource consumption of storage spaces. In this test, we set limited storage space at vehicles and use FIFO dropping rule to manage storage space. Thus, Epidemic leads to frequent change of the packages before they are forwarded. Thus, the performance of Epidemicrouting protocol deteriorates.

From qualitative analysis, the simulation results are in line with theoretical derivation. Thus, it testifies the correctness of statistic results using our platform to some extent and further shows the practicality of our platform in algorithm performance comparison.

In this section, we introduce two typical instances. One is a real application, real-time traffic monitoring, in order to show the usage of our simulator and indicate the practicality and convenience of our platform. The other is statistical analysis of three routing protocols, in order to testify the accuracy of simulation results qualitatively. However, more actual experiments are required in our future work to further evaluate the performance of BHU-VSim quantitatively.