0

I am working on a project using

  • inet 3.6.6
  • veins 5 with veins_inet3

I need to set a scenario using .poly.xml files generated in SUMO to model the obstacles in a city. I also need to use the IEEE 802.11p protocol available in veins. I'm facing two problems:

  1. I don't know how to include obstacles in the .poly.xml format when looking at the veins_inet example. I know that in inet (independently) I can include obstacles using the *.physicalEnvironment.config variable in the .ini file. However, I tried to include the .poly files and it didn't work. Do I need to include an obstacles module?

  2. I need to use the IEEE 802.11p protocol, however, I'm not completely sure how to do it. What I think could work is to include the veinsMobility module in my node and in that way the channel will be updated. Also, I'm not sure if I need to include the ConnectionManager module and the BaseWorldUtility.

I'll really appreciate any thoughts on this.

Tomás Lara
  • 23
  • 9

1 Answers1

2

The Veins radio stack (global modules world, connectionManager, obstacles, and vehicleObstacles and per-node modules appl, nic, and veinsmobility) is entirely separate from the INET Framework radio stack (global modules radioMedium, physicalEnvironment and per-node modules app, udp, ipv4, wlan, and mobility). Both can be configured to model various configurations of IEEE 802.11 WLAN, though both focus on different aspects. However, even the INET Framework can be configured to closely approximate a WLAN station using IEEE 802.11 OCB mode at 5.9 GHz ("802.11p"). The Veins module documentation goes into some more detail here.

The Veins radio stack (as of Veins 5.1), by default, instantiates all SUMO polygons that match a given type (the Veins 5.1 example configuration uses polygon type building) as radio obstacles. This is being done at run time, by querying a list of all existing polygons from the running SUMO simulation. In brief: there is typically no need to supply a manually-generated file with obstacle definitions; radio obstacles can be configured to simply "automatically" appear (again, as in the Veins 5.1 example configuration).

The INET Framework (as of version 4.3.0) does not allow dynamically creating radio obstacles at run time, so there is no "automatic" way to read and instantiate radio obstacles from SUMO polygons. Here, you would need to manually convert the SUMO .poly.xml file to an obstacles.xml definition file (or write a converter script to do that for you, which is straightforward to do).

Christoph Sommer
  • 6,893
  • 1
  • 17
  • 35
  • I imported RSU from veins to veins_inet. It by default has nic property connection manager defined to veins one. veins_inet doesn't have a 'connection manager'. What am I supposed to do for this? How to replace each of these veins world utility and such with inet ones? – Sandeepa Kariyawasam Apr 03 '21 at 09:18
  • If your goal is to make the RSU look like a mobile node (that is, a car) of `veins_inet` (the only difference being that it does not move like a car), I would suggest starting with the OMNeT++ module of a `veins_inet` car and changing the mobility to be static. – Christoph Sommer Apr 03 '21 at 09:22
  • I need it to function in DSRC and vehicles to function in either dsrc or wifi. Like different technologies in a single simulation. – Sandeepa Kariyawasam Apr 03 '21 at 10:24
  • @ChristophSommer sorry, but this is an untrivial topic. Assume I want to use a Simu5G/LTE network modules, which use underneath INET modules but to model it in SUMO environment. My SUMO's `test.poly.xml` converts objects from OSM file, however I want, of course, that 3D objects influence on 4/5G signal quality as well, which is only possible if I precisely define these objects in `obstacles.xml` and load into INET's `PhysicalEnvironment`. So I understand from your comment. But these two xml files use totally different tags and logic, do you have an example of an easy conversion between them? – gehirndienst Jun 17 '22 at 14:00
  • I could not think of an easy way of converting between the arbitrary polygons used by SUMO and (what I think I rembember as) convex prisms used by INET. The few times I needed to convert polygons I recall implementing a quick and dirty tesselation/cutting algorithm in C++ to write out an INET obstacle file to read in on the next run. – Christoph Sommer Jun 21 '22 at 05:50
  • in case somebody is interested: [here](https://github.com/panagis/ConvertOsmToInetObstacles) is a converter that does a dirty job. I only recommend to add `--buffer-size=` option to `pcregrep` commands in the script if you have a large poly file – gehirndienst Aug 26 '22 at 09:17