CODEWITHSUNDEEP
veinsinet
Tomás Lara
Tomás Lara

Reputation: 33

Obstacle files (poly.xml) and IEEE802.11p when using veins_inet

I am working on a project using

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.

Upvotes: 0

Views: 419

Answers (1)

Christoph Sommer
Christoph Sommer

Reputation: 6943

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).

Upvotes: 2

Related Questions