Veins

The open source vehicular network simulation framework.

Modules

In-depth information on select components.

Veins provides a comprehensive suite of IVC-specific models that can serve as a modular framework for simulating applications. Each model is contained in one or more of what OMNeT++ terms a module, which can be instantiated in a running simulation to provide required functionality.


Modular structure of Veins.

How to use each module is documented in the module itself in the form of doxygen comments. This can be transformed into API documentation by clicking Project > Generate NED Documentation... in the IDE, or from the command line, by running make doxy. To start reading the module documenation, open doc/index.html in your browser. This gives you the most up-to-date form of documentation specific to your version of Veins.

This page gives a brief overview of some modules that are either central to the functionality of Veins, not yet contained in the standard distribution, or that require more extensive documentation, in particular pictures or videos.


MiXiM

For accurate modeling of physical layer effects, especially for modelling and working with the distribution of transmit power over time and space, Veins relies on functionality provided by MiXiM, which has been integrated into Veins.


TraCI

Veins instantiates one network node per vehicle driving in SUMO. This task is handled by the TraCIScenarioManagerLaunchd module: it connects to a TraCI server (SUMO or sumo-launchd) and subscribes to events like vehicle creation and movement. For each vehicle created in SUMO, it instantiates one OMNeT++ Compound Module in the OMNeT++ simulation. This module is assumed to contain a mobility submodule of type TraCIMobility. At regular intervals it will use this module to advance the simulation in SUMO and update the node's mobility information (such as position, speed, and direction) based on the behavior of the vehicle. For quick tests, the TraCIMobility module also includes functionality to stop a vehicle at a predefined point in time (configured via its accidentStart, and accidentDuration parameters).

Full API documentation of these modules is available as documented above. The most interesting parameters of TraCIScenarioManagerLaunchd are:

updateInterval
the time interval between updates of the SUMO simulation
moduleType
which OMNeT++ module to instantiate for each driving vehicle
port
on which TCP port to connect to sumo-launchd
seed
which random number seed to configure SUMO for
roiRects
for only simulating vehicles currently driving within a ROI, that is, a Region of Interest

Application modules can use the TraCICommandInterface class and related classes, conveniently accessible from TraCIMobility, to interact with the running simulation. The following example shows how to make a vehicle aware of slow traffic on a road called Second Street, potentially causing it to change its route to avoid this road.

mobility = TraCIMobilityAccess().get(getParentModule());
traci = mobility->getCommandInterface();
traciVehicle = mobility->getVehicleCommandInterface();
traciVehicle->changeRoute("Second Street", 3600);


Some of the other vehicle related commands are setSpeed or setParking. Similar methods are available for the whole simulation (e.g., addVehicle, addPolygon), roads (getMeanSpeed), individual lanes (getShape), traffic lights (setProgram), polygons (setShape), points of interest, junctions, routes, vehicle types, or the graphical user interface.

How to use these modules is demonstrated in the source code of the Veins tutorial example. Again, a list of all 80+ available methods can be found in TraCICommandInterface.h or the autogenerated module documentation.


IEEE 802.11p and IEEE 1609.4 DSRC/WAVE

Veins includes a model of 802.11 that is tailored to use in vehicular networks, particularly IEEE 802.11p. This includes QoS channel access conforming to EDCA (that is, 4 queues with different access categories) and accurately captures frame timing, modulation and coding, and channel models.

Veins also includes higher layer models of the DSRC/WAVE stack for channel hopping according to the standard (i.e., switching between CCH and SCH, that is, control channel and service channel), if this is desired. It further includes Wave Short Message (WSM) handling, and periodic beaconing, e.g., for sending WAVE service announcements, BSMs, or CAMs.

Please refer to our publications for a detailed description of the model itself, including a thorough description and an evaluation.

  • David Eckhoff, Christoph Sommer and Falko Dressler, "On the Necessity of Accurate IEEE 802.11p Models for IVC Protocol Simulation," Proceedings of 75th IEEE Vehicular Technology Conference (VTC2012-Spring), Yokohama, Japan, May 2012, pp. 1-5. [DOI, BibTeX, PDF and Details...]
  • David Eckhoff and Christoph Sommer, "A Multi-Channel IEEE 1609.4 and 802.11p EDCA Model for the Veins Framework," Proceedings of 5th ACM/ICST International Conference on Simulation Tools and Techniques for Communications, Networks and Systems (SIMUTools 2012): 5th ACM/ICST International Workshop on OMNeT++ (OMNeT++ 2012), Poster Session, Desenzano, Italy, March 2012. [BibTeX, PDF and Details...]

How to use these modules is demonstrated in the source code of the Veins tutorial example.


ARIB STD-T109

A simulation model of the Japanese ARIB T109 standard for ITS in the 700 MHz band has recently been completed. It models both physical layer characteristics and medium access characteristics of the standard's unique combination of TDMA and CSMA/CA.

The MAC layer consists of two different implementations distinguishing between RSUs (base stations) and vehicles (mobile stations). Both share a common abstract base class which contains functionality utilized in both implementations. The MAC layer combines the CSMA/CA functionalitiy from IEEE 802.11p MAC and the IVC-RVC layer from ARIB T109 which utilizes the TDMA scheme.

The model is available on a separate branch of Veins (see the link below), which is only compatible with OMNeT++ 5. An example simulation is included as a separate ini file and can be executed, e.g., by running ./run -u Tkenv -f arib.ini in examples/veins.

Show differences on github

Please refer to our publication for a detailed description of the model itself, including a thorough description and an evaluation.


Two-Ray Interference Model

Path loss models are central to accurately modeling information propagation in a vehicular network. An often made, but wrong, assumption is that all signals propagate in close to free space conditions. In fact, particularly on linear unobstructed stretches of roads, any transmission experiences (depending on the distance) either constructive or destructive interference with its own ground reflection. Yet, the often-cited simplified Two-Ray ground model only captures the fact that (for the physics of vehicular networks), path loss increases for distances over approximately 900 meters. Veins therefore includes a Two-Ray Interference model which actually manages to capture ground reflection effects, as illustrated below.

This leads to quite different areas of good signal reception (left: two ray ground, right: two ray interference), as illustrated below in a top-down view.

Please refer to our publications for a detailed description of the model itself, including a thorough description and an evaluation.

The model can be activated by including an appropriate AnalogueModel statement in config.xml, e.g., as follows.

<AnalogueModel type="TwoRayInterferenceModel">
<parameter name="DielectricConstant" type="double" value="1.02"/>
</AnalogueModel>



Obstacle Shadowing

Radio transmissions are heavily impacted by signal shadowing effects. Accurately capturing this is particularly important in vehicular networks operating in suburban and urban environments, where buildings block radio propagation. Veins includes a simple obstacle shadowing model that has been calibrated and validated against real world measurements, as illustrated below.

This model will accurately capture the effect that large buildings will block transmissions and weak transmissions are blocked by as little as a small wall, while strong transmissions are only slightly hindered by the presence of buildings in the line of sight, as illustrated in the sample screencast below.

Please refer to our publications for a detailed description of the model itself, including a thorough description and an evaluation.

The model can be activated by adding an ObstacleControl module to the simulation and including an appropriate SimpleObstacleShadowing statement in config.xml, e.g., as follows. Aside from the ObstacleControl module offering the possibility to manually add obstacles to the simulation, the TraCIScenarioManagerLaunchd will automatically detect the presence of an ObstacleControl module and automatically instantiate one obstacle per polygon of type building in SUMO.

<AnalogueModel type="SimpleObstacleShadowing">
<parameter name="carrierFrequency" type="double" value="5.890e+9"/>
</AnalogueModel>


How to use these modules is demonstrated in the source code of the Veins tutorial example.


Antenna Patterns

A simulation model that captures angle-dependent gains of antennas has recently been completed. It includes parameters for different types of real-world antenna patterns, depending on antenna type, mounting point, and roof topology. An antenna pattern can be configured by setting a physical layer's antenna parameter to an XML statement configuring the type of antenna, along with type-dependent parameters. If no antenna pattern is specified, the physical layer defaults to 0 dBi gain isotropic.

At the moment, only one antenna pattern type, SampledAntenna1D, is implemented. It defines an antenna pattern using a single parameter, samples, which stores a series of gain samples, taken at equidistant intervals from 0 degress, going clockwise. This antenna also takes optional random-offsets and random-rotation parameters to add a random gain offset (in dBi), as well as a random rotation offset (in degrees) to each antenna.

The following is an example XML statement configuring such an antenna using very coarse (four) gain samples (+2.0 dBi to the front of the car, +1.1 dBi to the right of the car, -4.0 dBi to the back of the car, +0.9 dBi to the left of the car). This XML statement also applies a random +/- 1 dBi gain to each antenna, as well rotating the whole antenna pattern by a random +/- 1 degree.

<Antenna type="SampledAntenna1D" id="patch">
<parameter name="samples" type="string" value="2.0 1.1 -4.0 0.9"/>
<parameter name="random-offsets" type="string" value="uniform -1 1"/>
<parameter name="random-rotation" type="string" value="uniform -1 1"/>
</Antenna>


The model is included since Veins 4.5.

Browse commit b8637c on github

Please refer to our publication for a detailed description of the model itself, including a thorough description and an evaluation.


Veins_INET Subproject

Veins_INET is a subproject included with Veins, which allows using Veins as a mobility model in INET 3.4.0.

The subproject can be imported into the OMNeT++ IDE by importing the subprojects/veins_inet folder into the workspace (or by selecting the Search for nested projects when importing Veins).

An example simulation in the examples/veins_inet subdirectory of the project illustrates how Veins_INET is used: Wireless nodes representing cars can inherit from the standard INET WirelessHost, using a regular INET network card, e.g., of type Ieee80211MgmtAdhoc along with a full TCP/IP stack. Each car uses a mobility module of type VeinsInetMobility to track its position. To configure the network stack of cars entering a simulation, an additional HostAutoConfigurator module needs to be included with each car. A global module, VeinsInetManager, creates and manages cars in the simulation.

This subproject is included since Veins 4.5.


Veins LTE Extension

Veins LTE is an extension which allows Veins to serve as a unified Open Source framework for the simulation of heterogeneous vehicular networks using, for example, IEEE 802.11p DSRC, Wi-Fi, and LTE.

It integrates Veins and two additional module libraries:

  • Veins continues to provide simulation models of DSRC vehicular networks;
  • The INET Framework provides general IP connectivity support and models of links using IEEE 802.11 Wi-Fi;
  • SimuLTE provides the means of simulating cellular networks using LTE.

Veins LTE is available as a separate download from the following website.

Visit Website

Please refer to the following publication for a detailed description of the Veins LTE extension.


Plexe: Platooning Extension for Veins

Plexe is an extension of Veins which permits the realistic simulation of platooning (i.e., automated car-following) systems. It features realistic vehicle dynamics and several cruise control models, permitting the analysis of control systems, large-scale and mixed scenario, as well as networking protocols and cooperative maneuvers.

Plexe is available as a separate download from the following website.

Visit Website

Please refer to the following publication for a detailed description of the Plexe extension.


Artery: ETSI ITS-G5 protocol simulation in Veins

Artery is an extension of Veins which enables V2X simulations based on ETSI ITS-G5 protocols like GeoNetworking and BTP. Single vehicles can be equipped with multiple ITS-G5 services through Artery's middleware, which also provides common Facilities for these services.

The closely related ArteryLTE is an extension of Veins LTE (see above) that also includes backend functionality.

Artery and ArteryLTE are available as separate downloads from the following website.

Visit Artery Website Visit ArteryLTE Website

Please refer to the following publication for a detailed description of the Artery extension.

  • Raphael Riebl, Hendrik-Jörn Günther, C. Facchi and L. Wolf, "Artery - Extending Veins for VANET Applications," Proceedings of 4th International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS 2015), Budapest, Hungary, Jun 2015. [DOI, BibTeX, Details...]

PREXT: Privacy extension for Veins

PREXT is a unified and extensible framework that simulate pseudonym change schemes (i.e. privacy schemes) in VANET. It supports seven privacy schemes of different approaches including silent period, context-based and mix-zone and can be easily extended to include more schemes. It includes adversary modules that can eavesdrop vehicle messages and track their movements. This adversary is used in measuring the gained privacy in terms of several popular metrics such as entropy, traceability and pseudonym usage statistics.

PREXT is available as a separate download from the following website.

Visit PREXT Website

Please refer to the following publication for a detailed description of the PREXT extension.

  • Karim Emara, "Poster: PREXT: Privacy Extension for Veins VANET Simulator," Proceedings of 8th IEEE Vehicular Networking Conference (VNC 2016), Poster Session, Columbus, OH, December 2016. [DOI, BibTeX, Details...]

Further Modules

A complete list of all available modules as well as full API documentation is available from the downloaded Veins source bundle as documented above.