Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
|Date:||Jan 19, 2011|
|Organization:||University of Luxembourg|
|Copyright:||2010-2011, University of Luxembourg|
The general aim of this project is to allow online simulation for vehicular applications by integrating traffic simulation (SUMO) and netwok simulation (ns-3). vehicles.
The traffic simulator used here is sumo. It’s a microscopic level simulator, it means that it produces mobility at the level of the vehicle, taking into account vehicles level problems like speedup, slow downs, lane changing, passing by. It also considers vehicles’ environment like traffic lights, speed limit and of course the other
To achieve microsimulation SUMO first needs a network representing roads, streets, junctions, and other environmental entities. They it needs vehicles to run into this network. Each vehicle has to be given an initial route (a set of edges from the above network) and a departure time.
This information is given to the simulator through xml configuration files the following ones are the mandatory ones, other optional file that can be used to gather localized information (detectors) or to give more elements to the map (buildings, areas...):
- the network file (name by convention with extension .net.xml) that contains the definition of the environment (roads, junction, traffic lights, speed limits, number of lanes...)
- the route file (named by convention with extension .rou.xml) that contains the definition of the vehicles with their route and departure time.
- a global configuration file (named by convention with extension .sumo.conf) that gives the path of all the other, so as other parameters.
Once the configuration is set up, the microsimulation can start. the output of the simulation is computed the step by step (on a millisecond bases) position and speed of the vehicles. From the environment point of view, some aggregated data can also be computed. the predefined detectors will output files with aggregated data like the evolution of the traffic through a given edge or the average speed.
The most practical way to get the output of the simulation is through the Traci interface; a client/server approach that allows the communication with SUMO. With Traci you may not only get simulation output but you may also drive the simulator and change it’s behavior.
The Traci client/server approach allows both to gather information about the ongoing simulation and to drive it, changing values in the environment (e.g. max speed, traffic light logic), or in the set of vehicles (e.g. modify one vehicle’s route). Traci also drives the simulation steps. The Traci architecture relies on a set of commands that are passed to the simulator. At runtime, if specified int he configuration file, SUMO starts a server that listens for commands on a given tpc/ip port. The client can be any other tool using the same protocol and port. The client can be located on the same machine or on any other machine on the same network.
Sumo is a paquet level simulator, for wired and wireless networks. It allows the simulation of a wide variety of network architectures. We focus here on the wireless part where not only the protocol implementation but also the mobility and the physical issues inherent to signal transmission is handled.
Ns-3 simulates a set of nodes. Each node may be equipped with multiple network interfaces, it is also linked to a mobility model. Finally the main activity of the simulator is described in nodes applications, that define for each node it’s behavior regarding the network.
Classically, one main program called script, handles the all setup of the network, the creation and initialization of nodes and the main simulation loop. The main steps of this script are as shown on the following diagram.
Ns-3’s classical main script.
The ovnis platform links the two previous simulators together. Simply one can consider that SUMO’s vehicles are ns-3’s nodes, however it is possible to consider only a subset of vehicles to be equipped with communication devices. The main diference if the two paradigms is the dynamics: even if nodes can move (that’s to their mobility model), they are supposed to exist from the beginning of the simulation to the end. For SUMO, vehicles may appear or disappear at any moment of the simulation. OVNIS brings this anytime creation/deletion of nodes to ns-3. The naming system is another different between the two simulator. OVNIS provides a binding between both naming system so as each node in ns-3 is liked to one and only one given vehicle.
OVNIS uses both paradigms however the ns-3 paradigm is favored for the setup of the different options. So if you are already aware of the ns-3 coding paradigms and architectures, then you should quickly get used to OVNIS. It re-defines the idea of general script and also gives new features to nodes applications.
From the global configuration point of view, It can be seen as an extra layer to the classical ns-3 main script. The following figure can sketch how an OVNIS script looks like. Note that the red boxes on the drawing are the new steps compared to the classical ns-3 script.
Ovnis’ main script.
Main ideas of that script are identical to the ones in a classical ns-3 script, except that the creation and start of nodes is not a one-time procedure since new nodes may appear at each time step. Nodes may also disappear. Ovnis’ job here is to properly handle the online creation and removal of nodes, not natively provided by ns-3. Moreover that new script handles proactively the execution of the traffic simulator.
From the localized level of nodes, OVNIS brings the ability to interact with the traffic simulator. That last one is then considered as an onboard navigation device (equipped with a GPS). Nodes may then ask a number of information related to their position, speed and route. They may also decide to change route and order the traffic simulator to make the corresponding vehicle change its route.