index.xml - gerrit/www.eclipse.org/mosaic - Git at Google

 <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
   <channel>
     <title>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</title>
     <link>https://www.eclipse.org/mosaic/</link>
       <atom:link href="https://www.eclipse.org/mosaic/index.xml" rel="self" type="application/rss+xml" />
     <description>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</description>
     <generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator><language>en-us</language><lastBuildDate>Mon, 18 Jan 2021 00:00:00 +0000</lastBuildDate>
     <image>
       <url>https://www.eclipse.org/mosaic/images/logo.svg</url>
       <title>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</title>
       <link>https://www.eclipse.org/mosaic/</link>
     </image>

     <item>
       <title>Communication in Applications</title>
       <link>https://www.eclipse.org/mosaic/docs/develop_applications/communication/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/develop_applications/communication/</guid>
       <description>&lt;p&gt;Eclipse MOSAIC has different classes, which allow you to define the network type and the specific area where the
 communication should occur. Communication can be achieved with external
 network simulators (
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/&#34;&gt;OMNeT++&lt;/a&gt;,
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/&#34;&gt;ns-3&lt;/a&gt;) or one of the built-in communication simulators
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns/&#34;&gt;SNS&lt;/a&gt;
 or
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_cell/&#34;&gt;Eclipse MOSAIC Cell&lt;/a&gt;. Furthermore, for a better understanding it is important to consider the network types of Eclipse MOSAIC in more
 detail.&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Cellular Communication&lt;/li&gt;
 &lt;li&gt;Ad-hoc Communication&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;Depending on the needs of the application, there are different approaches to solve the communication issue in Eclipse MOSAIC
 simulations. However, a distinction must be made between inter vehicle communication and Vehicle-to-X communication.
 Also, it is possible to modify the selected communication mode dependent on requirements.&lt;/p&gt;
 &lt;p&gt;Generally, the following modes are available based on network:&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Cellular Communication&lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Geobroadcast&lt;/li&gt;
 &lt;li&gt;Geocast&lt;/li&gt;
 &lt;li&gt;Topocast&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;&lt;strong&gt;Ad-hoc Communication&lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Geobroadcast&lt;/li&gt;
 &lt;li&gt;Geocast&lt;/li&gt;
 &lt;li&gt;Topobroadcast&lt;/li&gt;
 &lt;li&gt;Topocast&lt;/li&gt;
 &lt;/ul&gt;
 &lt;hr&gt;
 &lt;h2 id=&#34;cellular-communication&#34;&gt;Cellular Communication&lt;/h2&gt;
 &lt;p&gt;The cellular network is known from wireless mobile communication and the principle is to divide the entire geographic
 area into several smaller parts called &lt;strong&gt;&amp;ldquo;cells&amp;rdquo;&lt;/strong&gt;. Each cell has a fixed-location transceiver with a coverage ratio.&lt;/p&gt;
 &lt;p&gt;Eclipse MOSAIC enables the communication with all the existing vehicles via Geobroadcast mode or direct communication via
 Geocast in a specific area (circular, rectangular). In contrast, the Topocast mode is not restricted to a specific area.&lt;/p&gt;
 &lt;h3 id=&#34;cellular-geobroadcast&#34;&gt;Cellular Geobroadcast&lt;/h3&gt;
 &lt;p&gt;The principle function of the Geobroadcast is to communicate with all entities within a geographical area. Eclipse MOSAIC
 offers the possibility to configure a specific geographical area which can be either a circular or a rectangular area.&lt;/p&gt;
 &lt;p&gt;The following figure illustrates a vehicle &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; which is communicating with the other
 vehicles(&lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt;) within a radius &lt;strong&gt;R&lt;/strong&gt;.&lt;/p&gt;


 &lt;figure id=&#34;figure-illustration-of-geobroadcast-in-a-spezific-circular-area&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geobroadcast-circular-area.png&#34; data-caption=&#34;Illustration of Geobroadcast in a spezific circular area&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-geobroadcast-circular-area.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Illustration of Geobroadcast in a spezific circular area
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;A circular communication area can be defined with the &lt;code&gt;geoBroadCast(GeoCircle geoCircle)&lt;/code&gt; from an Eclipse MOSAIC application,
 as shown below:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoCircle transmissionArea = new GeoCircle(GeoPoint.latlon(52.5, 13.2), 3000);

 MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;A rectangular destination area can be defined similarly:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint pointA = GeoPoint.latlon(52.51355, 13.22000);
 GeoPoint pointB = GeoPoint.latlon(52.52000, 13.21000);
 GeoRectangle transmissionArea = new GeoRectangle(pointA, pointB);

 MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;cellular-geocast&#34;&gt;Cellular Geocast&lt;/h3&gt;
 &lt;p&gt;Compared to Geobroadcasting, a Geocast addresses a receiver with an unique address. Addressing can be in the form of an
 IP-Address or a receiver-ID (e.g. veh_0). Again, the communication area can be configured as circular or rectangular.&lt;/p&gt;
 &lt;p&gt;Assume, the &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; has a message which is addressed to &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;. In order to send the message, &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; first
 examines whether the vehicle with ID &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; is located within the transmission area. If this is the case, the
 message will be transmitted. In figure below is this situation illustrated.&lt;/p&gt;


 &lt;figure id=&#34;figure-cellular-geocast-to-address-a-receiver-within-a-defined-area&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geocast-circular-area.png&#34; data-caption=&#34;Cellular Geocast to address a receiver within a defined area&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-geocast-circular-area.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Cellular Geocast to address a receiver within a defined area
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;The following methods are provided for the configuring the transmission area (Circle or Rectangle) and the addressing to
 the receiver(hostname or ip address).&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;geoCast(GeoCircle geoCircle, String receiverName) &lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;geoCast(GeoRectangle geoRectangle, String receiverName)&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;geoCast(GeoCircle geoCircle, byte[] ipAddress)&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;geoCast(GeoRectangle geoRectangle, byte[] ipAddress)&lt;/code&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000);

 String receiverName = &amp;quot;veh_0&amp;quot;;
 MessageRouting routing = getOs().getCellModule().createMessageRouting().geoCast(transmissionArea, receiverName);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;cellular-topocast&#34;&gt;Cellular Topocast&lt;/h3&gt;
 &lt;p&gt;Compared to Geocast or Geobroadcast, the Topocast is totally independent of geographical conditions and the addressing
 can be in the form of an IP-Address or a receiver-ID.&lt;/p&gt;
 &lt;p&gt;The next figure illustrates how the &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt; is communicating with &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; in Topocast mode.&lt;/p&gt;


 &lt;figure id=&#34;figure-topocast-mode-for-direct-addressing-without-geographical-constraints&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-cellular-topocast.png&#34; data-caption=&#34;Topocast mode for direct addressing without geographical constraints&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-cellular-topocast.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Topocast mode for direct addressing without geographical constraints
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;The code example below shows how we can configure the requirements of the communication in Topocast mode.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;String receiverName = &amp;quot;veh_0&amp;quot;;

 MessageRouting routing = getOs().getCellModule().createMessageRouting().topoCast(receiverName);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;setting-protocol-types&#34;&gt;Setting Protocol types&lt;/h3&gt;
 &lt;p&gt;By default, all cell messages use UDP, however you can set the protocol using the &lt;code&gt;protocol(...)&lt;/code&gt; method of the &lt;code&gt;MessageRoutingBuilder&lt;/code&gt;:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;String receiverName = &amp;quot;veh_0&amp;quot;;

 MessageRouting routing = getOs().getCellModule().createMessageRouting()
         .protocol(Protocoltype.TCP)
         .topoCast(receiverName);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;hr&gt;
 &lt;h2 id=&#34;ad-hoc-communication&#34;&gt;Ad-hoc Communication&lt;/h2&gt;
 &lt;p&gt;The Ad-hoc network does not rely on a pre-existing infrastructure. Provided that vehicles are equipped with Ad-hoc
 modules, they are able to communicate with each other dynamically. In case of a sufficient number of Ad-hoc equipped
 vehicles, a message can be transferred via hops quickly over a long distance.&lt;/p&gt;
 &lt;p&gt;Eclipse MOSAIC also enables the communication via a specific Ad-hoc channel within the wireless Ad-hoc network. However, the
 Ad-hoc channels for vehicular communication are limited and standardized by the IEEE 802.11p.
 The licensed frequency band 5.9 GHz (5.85-5.925 GHz) for Intelligent Transportation Systems(ITS) will be used as Ad-hoc
 channels.&lt;/p&gt;
 &lt;p&gt;The following table shows the possible channels on the 5.9 GHz band used for V2X communication.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Channel Number&lt;/th&gt;
 &lt;th&gt;0&lt;/th&gt;
 &lt;th&gt;1&lt;/th&gt;
 &lt;th&gt;2&lt;/th&gt;
 &lt;th&gt;3&lt;/th&gt;
 &lt;th&gt;4&lt;/th&gt;
 &lt;th&gt;5&lt;/th&gt;
 &lt;th&gt;6&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Channel Name&lt;/td&gt;
 &lt;td&gt;SCH1&lt;/td&gt;
 &lt;td&gt;SCH2&lt;/td&gt;
 &lt;td&gt;SCH3&lt;/td&gt;
 &lt;td&gt;CCH&lt;/td&gt;
 &lt;td&gt;SCH4&lt;/td&gt;
 &lt;td&gt;SCH5&lt;/td&gt;
 &lt;td&gt;SCH6&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Frequency Band&lt;/td&gt;
 &lt;td&gt;5.86&lt;/td&gt;
 &lt;td&gt;5.87&lt;/td&gt;
 &lt;td&gt;5.88&lt;/td&gt;
 &lt;td&gt;5.89&lt;/td&gt;
 &lt;td&gt;5.9&lt;/td&gt;
 &lt;td&gt;5.91&lt;/td&gt;
 &lt;td&gt;5.92&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;configuring-adhoc-capabilities&#34;&gt;Configuring AdHoc Capabilities&lt;/h3&gt;
 &lt;p&gt;The first step to enable your application to use Ad hoc capabilities, is to make sure it extends the &lt;code&gt;AbstractSimulationUnit&lt;/code&gt;-class
 or one of its child-classes (e.g. &lt;code&gt;VehicleUnit&lt;/code&gt;, &lt;code&gt;ChargingStationUnit&lt;/code&gt;) found in package
 &lt;code&gt;org.eclipse.mosaic.fed.application.ambassador.simulation&lt;/code&gt;. Additionally, if you want your application to act upon
 the reception or transmission of messages, make sure it implements the interface &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;br&gt;
 Once this is done, make sure to configure and enable the AdHoc-module in your application. Below is an example configuration
 taken from the Tiergarten-tutorial. Instead of configuring the &lt;code&gt;.power(...)[mW]&lt;/code&gt; it is also possible to configure
 a &lt;code&gt;.distance(...)[m]&lt;/code&gt;.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;// Example of AdHocConfiguration (see TiergartenVehicle.java)
 @Override
 public void onStartup() {
     getOs().getAdHocModule().enable(new AdHocModuleConfiguration()
         .addRadio()
         .channel(AdHocChannel.CCH)
         .power(50)
         .create());
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;ad-hoc-topobroadcast&#34;&gt;Ad-hoc Topobroadcast&lt;/h3&gt;
 &lt;p&gt;In Topobroadcast mode, the communication between vehicles is regardless of the geographic conditions. However, the
 communicating entities must be operated on the same Ad-hoc channel and there are two options to use the Topobroadcast:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Singlehop&lt;/li&gt;
 &lt;li&gt;Multihop&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;singlehop-approach-in-topobroadcast&#34;&gt;Singlehop approach in Topobroadcast&lt;/h4&gt;
 &lt;p&gt;For Singlehop, it is not necessary to specify the number of hops explicitly which indicates the lifespan of a message,
 because in Singlehop, any message has a lifespan of &lt;strong&gt;hop = 1&lt;/strong&gt;. Moreover, Eclipse MOSAIC allows to use the default method
 &lt;code&gt;topoBroadCast()&lt;/code&gt; which automatically assigns a Control Channel (CCH) for the simulation entity and a lifespan based on
 the Singlehop principle. Alternatively you can use the non-default method &lt;code&gt;topoBroadCast(AdHocChannel)&lt;/code&gt; in order to
 specify the Ad-hoc channel.&lt;/p&gt;
 &lt;p&gt;Below are some configuration examples of the default addressing method &lt;code&gt;topoBroadCast()&lt;/code&gt; and non-default addressing
 method &lt;code&gt;topoBroadCast(AdHocChannel)&lt;/code&gt;.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast();

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;AdHocChannel commonChannel = AdHocChannel.SCH1;

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel);

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The following figure shows a simplified model based on the Singlehop principle. The &lt;em&gt;veh_1&lt;/em&gt; sends messages to all
 simulation entites(&lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;) that are using the same Ad-hoc channel. After transmission, the message can
 no longer be forwarded by the receiver.&lt;/p&gt;


 &lt;figure id=&#34;figure-overview-singlehop-with-specified-ad-hoc-channel&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-topobroadcast-singlehop.png&#34; data-caption=&#34;Overview Singlehop with specified Ad-hoc channel&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-adhoc-topobroadcast-singlehop.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Overview Singlehop with specified Ad-hoc channel
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h4 id=&#34;multihop-approach-in-topobroadcast&#34;&gt;Multihop approach in Topobroadcast&lt;/h4&gt;
 &lt;p&gt;In Multihop, the lifespan (amount of hops) of a message can be specified, allowing larger communication distances.&lt;/p&gt;
 &lt;p&gt;The following figure shows a Multihop example with a data package D (M, h = 2) from the vehicle &lt;em&gt;veh_0&lt;/em&gt; which contains a
 message M and a hop number h = 2. Assuming that a lot of simulation entities are using the same Ad-hoc channel the
 message can be forwarded over a along distance. After each forward the hop number will be incremented by 1. Since the
 hop amount was set to 2, the forwarding will stop after 2 increments.&lt;/p&gt;


 &lt;figure id=&#34;figure-overview-multihop-principle&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-topobroadcast.png&#34; data-caption=&#34;Overview Multihop principle&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-adhoc-topobroadcast.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Overview Multihop principle
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;The next code snippet shows a configuration example with an Ad-hoc channel and a message lifespan &lt;strong&gt;hops = 2&lt;/strong&gt;.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;AdHocChannel commonChannel = AdHocChannel.SCH1;
 int hops = 2;

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel, hops);

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;In order to use the Multihop approach in OMNeT++ and ns-3 provided by Eclipse MOSAIC, its necessary to implement a
 routing protocol in network simulators (&lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/&#34;&gt;OMNeT++&lt;/a&gt;, &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/&#34;&gt;ns-3&lt;/a&gt;). But the
 built in communication simulator &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns/&#34;&gt;SNS&lt;/a&gt; includes a simple routing protocol “Flooding”.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;h3 id=&#34;ad-hoc-topocast&#34;&gt;Ad-hoc Topocast&lt;/h3&gt;
 &lt;p&gt;In addition to the Topobroadcast, the communication in Topocast mode will be addressed explicitly to the recipient and
 the addressing can be done either through receiver name (vehicle-ID e.g. veh_0) or the IP-Address of the vehicle.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;final byte[] ipv4Address = {127,36,50,4};

 AdHocChannel commonChannel = AdHocChannel.SCH1;

 int hops = 2;

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoCast(ipv4Address, hops, commonChannel);

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;ad-hoc-geobroadcast&#34;&gt;Ad-hoc Geobroadcast&lt;/h3&gt;
 &lt;p&gt;In contrast to Cellular Network above, the simulation entities act as active communication part (transmitter and
 receiver) and all simulation entities within range are getting messages in Geobroadcast mode.&lt;/p&gt;
 &lt;p&gt;As example in the following illustration, The vehicles &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt; and the &lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt; are
 Ad-hoc equipped and there is no vehicle in the communication range of &lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt;, therefore a hop is not possible to next
 vehicle &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt;. But the vehicles &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; and &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt; are able to communicate with each other.&lt;/p&gt;


 &lt;figure id=&#34;figure-principle-of-ad-hoc-geobroadcast-mode&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-network.png&#34; data-caption=&#34;Principle of Ad-hoc Geobroadcast mode&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-adhoc-network.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Principle of Ad-hoc Geobroadcast mode
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;With the methods&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;geoBroadCast(GeoCircle geoCircle)&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;geoBroadCast(GeoRectangle geoRectangle)&lt;/code&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;of the Eclipse MOSAIC class &lt;code&gt;AdHocMessageRoutingBuilder&lt;/code&gt; ,we are able, to configure the required area as a circle or a
 rectangle.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint center = GeoPoint.latlon(52.5, 13.2);

 GeoCircle adHocModule = new GeoCircle(center, 3000);

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoBroadCast(adHocModule);

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Analogous to the examples above, we can also configure the transmission area as a rectangle.&lt;/p&gt;
 &lt;p&gt;The next code snippet illustrates a possible configuration with a rectangular transmission area and a specified Ad-hoc
 channel.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint pointA = GeoPoint.latlon(52.51355, 13.22000);

 GeoPoint pointB = GeoPoint.latlon(52.52000, 13.21000);

 final double radius = 3000.0;

 GeoRectangle transmissionArea = new GeoRectangle(pointA, pointB);

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoBroadCast(transmissionArea, AdHocChannel.SCH1);

 getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;ad-hoc-geocast&#34;&gt;Ad-hoc Geocast&lt;/h3&gt;
 &lt;p&gt;The class AdHocMessageRoutingBuilder only has one method for Geocasting mode,
 &lt;code&gt;geoCast(DestinationAddress destinationAddress, AdHocChannel adHocChannel)&lt;/code&gt;. Communication is possible if the
 IP-address of receiver is known and both (receiver and transmitter) are on the same Ad-hoc channel.&lt;/p&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;In this context the name Geocast is misleading, because a geological condition is not necessary.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;As you can see in the next picture, the RSU uses the Ad-hoc channel &lt;em&gt;SCH1&lt;/em&gt; and several vehicles use different
 Ad-hoc channels. Assuming the RSU tries to send a message to &lt;em&gt;veh_1&lt;/em&gt; and has knowledge about the IP-Address of &lt;em&gt;veh_1&lt;/em&gt;,
 if the vehicle &lt;em&gt;veh_1&lt;/em&gt; also uses the same channel &lt;em&gt;SCH1&lt;/em&gt;, the transmission will be completed successfully.&lt;/p&gt;


 &lt;figure id=&#34;figure-ad-hoc-geocast-communication-between-entities-using-the-same-channel&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geocast-adHoc.png&#34; data-caption=&#34;Ad-hoc Geocast communication between entities using the same channel&#34;&gt;


   &lt;img src=&#34;../images/tiergarten-geocast-adHoc.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Ad-hoc Geocast communication between entities using the same channel
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Below you can see a possible configuration.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;final byte[] ipv4Address = {127,36,50,4};

 DestinationAddress destAddress = new DestinationAddress(ipv4Address);

 AdHocChannel commonChannel = AdHocChannel.SCH1;

 MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoCast(destAddress, commonChannel);

 getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h2 id=&#34;cam---implementation&#34;&gt;CAM - Implementation&lt;/h2&gt;
 &lt;p&gt;A Cooperative Awareness Messages (CAM) consists of four parts:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Header with generic information&lt;/li&gt;
 &lt;li&gt;MessageBody&lt;/li&gt;
 &lt;li&gt;ServiceList&lt;/li&gt;
 &lt;li&gt;TaggedValue list&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;First, generic information like protocol version, creation time stamp are submitted. Normally this data set follows a network beacon, which already contains data like position and speed. Nevertheless, this functionality must be implemented in the network layer, that means in the network simulator. At the moment this is not supported and is therefore compensated in the next message part, the message body. The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is submitted, but this probably changes with a new CAM specification. In the second case, we provide date like vehicle width, length, position, speed, type and heading. The specification is not completely implemented, especially acceleration data and light, brake status are missing. The third part of the CAM specification, the service list, is also not implemented. This will probably change, when a list of services is defined by the ETSI. Last but not least a message contains a tagged list, a key value map with optional data. This is fully implemented and is used for our traffic light CAM messages, which provide the traffic light status in such a list.&lt;/p&gt;
 &lt;h3 id=&#34;user-defined-tagged-values&#34;&gt;User defined tagged values&lt;/h3&gt;
 &lt;p&gt;If you are required to exchange custom data within CAMs, the field UserTaggedValue can be used. For adding such data to the CAM, the application needs to implement the method &lt;code&gt;beforeGetAndResetUserTaggedValue()&lt;/code&gt; from the &lt;code&gt;CommunicationApplication&lt;/code&gt; interface. If a CAM is about to be sent, the custom data can be set using the &lt;code&gt;getOs().setUserTaggedValue(byte[])&lt;/code&gt; method. The receiver can simple access the data by accessing the field directly from the received CAM message:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;    byte[] value = cam.getUserTaggedValue ();
     if (value  != null) {
         // read  user  tagged  value}
     }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;timing-requirements&#34;&gt;Timing Requirements&lt;/h3&gt;
 &lt;p&gt;CAMs are generated by the CAM Management and passed to lower layers when any of following rules apply:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;maximum time interval between CAM generations: $1s$;&lt;/li&gt;
 &lt;li&gt;minimum time interval between CAM generations: $0.1s$;&lt;/li&gt;
 &lt;li&gt;generate CAM when absolute difference between current heading (towards North) and last CAM heading &amp;gt; $4 deg$;&lt;/li&gt;
 &lt;li&gt;generate CAM when distance between current position and last CAM position &amp;gt; $5m$&lt;/li&gt;
 &lt;li&gt;generate CAM when absolute difference between current speed and last CAM speed &amp;gt; $1ms$;&lt;/li&gt;
 &lt;li&gt;These rules are checked latest every $100ms$;&lt;/li&gt;
 &lt;/ul&gt;
 </description>
     </item>

     <item>
       <title>Event Scheduling</title>
       <link>https://www.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</link>
       <pubDate>Sun, 11 Aug 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</guid>
       <description>&lt;p&gt;The different modules of the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/application_simulator/#eclipse-mosaic-application-simulator&#34;&gt;Application Simulator&lt;/a&gt; communicate over events that are triggered at a specific simulation time. The following classes and interfaces model theses events.&lt;/p&gt;
 &lt;h3 id=&#34;event&#34;&gt;Event&lt;/h3&gt;
 &lt;p&gt;The class &lt;code&gt;Event&lt;/code&gt; contains the information that is necessary to process an event. An event describes when it should be processed and which information is processed. Moreover an event has an assigned priority.&lt;/p&gt;
 &lt;h4 id=&#34;attributes-of-event&#34;&gt;Attributes of Event&lt;/h4&gt;
 &lt;p&gt;The class Event contains the following attributes:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;long time&lt;/code&gt;: defines the time when the execution of the event is triggered.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;long nice&lt;/code&gt;: defines the priority of the event. When multiple events are scheduled for the sametime, the events are ordered in ascending order.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;List&amp;lt;EventProcessor&amp;gt; processors&lt;/code&gt;: is a list of components that shall process the event.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;Object resource&lt;/code&gt;: is an object that contains additional information designated for the processor of the event. The resource can be any object.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;methods-of-event&#34;&gt;Methods of Event&lt;/h4&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;Event()&lt;/code&gt;: There are multiple constructors for Event with different parameters. Every constructor sets default values for the attributes that are not defined by the arguments of the constructor.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;Event newTime(long time)&lt;/code&gt;: allows the creation of a new event with a new execution time based&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;String getResourceSimpleClassName()&lt;/code&gt;: returns the class name of the resource as String.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;int compareTo(Event event)&lt;/code&gt;: implements the standardized Java interface
 &lt;a href=&#34;https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Comparable&lt;/a&gt;.  Toorder the events, first the time of the event is evaluated. In case the times are equal, the priority of the events is compared.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h3 id=&#34;interface-eventmanager&#34;&gt;Interface EventManager&lt;/h3&gt;
 &lt;p&gt;The interface &lt;code&gt;EventManager&lt;/code&gt; defines the method &lt;code&gt;void addEvent(Event event)&lt;/code&gt; that needs to be implemented to add an event to the execution.&lt;/p&gt;
 &lt;h3 id=&#34;interface-eventscheduler&#34;&gt;Interface EventScheduler&lt;/h3&gt;
 &lt;p&gt;The interface &lt;code&gt;EventScheduler&lt;/code&gt; extends the interface &lt;code&gt;EventManager&lt;/code&gt; and is used for classes that trigger events.&lt;/p&gt;
 &lt;h4 id=&#34;methods-of-eventscheduler&#34;&gt;Methods of EventScheduler&lt;/h4&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;boolean isEmpty()&lt;/code&gt;: returns true if the scheduler contains no elements, otherwise it returns false.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;long getNextEventTime()&lt;/code&gt;: returns the time of the next event.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;long getScheduledTime()&lt;/code&gt;: returns the time when the last event has been executed.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;List&amp;lt;Event&amp;gt; scheduleEvents(long time)&lt;/code&gt;: returns a list of objects that are scheduled for a
 certain simulation time.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;Set&amp;lt;Event&amp;gt; getAllEvents()&lt;/code&gt;: returns a set of all events that are considered by the scheduler.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h3 id=&#34;eventschedulerimpl&#34;&gt;EventSchedulerImpl&lt;/h3&gt;
 &lt;p&gt;The class &lt;code&gt;EventSchedulerImpl&lt;/code&gt; is an implementation of the interface &lt;code&gt;EventScheduler&lt;/code&gt;.&lt;/p&gt;
 &lt;h3 id=&#34;interface-eventprocessor&#34;&gt;Interface EventProcessor&lt;/h3&gt;
 &lt;p&gt;The interface &lt;code&gt;EventProcessor&lt;/code&gt; defines how the execution module gets the events. The execution module
 therefore has to implement the following methods:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;void processEvent(Event event)&lt;/code&gt;: The module processes the event.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;boolean canProcessEvent()&lt;/code&gt;: returns true when the module is currently able to process new
 events, otherwise it returns false.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h3 id=&#34;interceptedevent&#34;&gt;InterceptedEvent&lt;/h3&gt;
 &lt;h3 id=&#34;class-eventinterceptor&#34;&gt;Class EventInterceptor&lt;/h3&gt;
 &lt;p&gt;In some situation it is useful to intercept events before they actually reach the intended processors. By
 intercepting the events it is possible to apply further monitoring and to filter which events the event
 processors receive. The class &lt;code&gt;EventInterceptor&lt;/code&gt; is used to construct objects of the type &lt;code&gt;InterceptedEvent&lt;/code&gt;.
 In the constructor it is possible to specify an EventManager that manages the intercepted events. Moreover, objects of the type &lt;code&gt;EventProcessor&lt;/code&gt; can be specified that shall process the intercepted events.&lt;/p&gt;
 &lt;h3 id=&#34;class-interceptedevent&#34;&gt;Class InterceptedEvent&lt;/h3&gt;
 &lt;p&gt;The class &lt;code&gt;InterceptedEvents&lt;/code&gt; extends the class Event. It is used to provide type safe allocations of
 events that shall be intercepted.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Scenario Database</title>
       <link>https://www.eclipse.org/mosaic/docs/develop_applications/road_traffic/</link>
       <pubDate>Tue, 06 Aug 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/develop_applications/road_traffic/</guid>
       <description>&lt;p&gt;Each scenario to be simulated with Eclipse MOSAIC requires a database which contains information about the road infrastructure and routes the
 vehicles drive on. This information is used by various federates. For example, the SUMO federate needs to know initial routes for vehicles,
 and the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/application_simulator/&#34;&gt;Application Simulator&lt;/a&gt; requires detailed information about the road
 infrastructure to provide applications with methods for route calculation. For this purpose, an embedded SQLite database is
 used which is placed in the &lt;code&gt;application&lt;/code&gt; folder of the scenario. This database consists of the following tables:&lt;/p&gt;
 &lt;h3 id=&#34;database-tables&#34;&gt;Database tables&lt;/h3&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Database Name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Node&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Contains all Nodes of the road network such as junctions and nodes describing the geometry of a road. Each node is identified by an unique ID (long).(refer to &lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Node&#34; target=&#34;_blank&#34;&gt;http://wiki.openstreetmap.org/wiki/Node&lt;/a&gt;)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Way&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provides various properties for each way of the road network.(refer to &lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Way&#34; target=&#34;_blank&#34;&gt;http://wiki.openstreetmap.org/wiki/Way&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;WayConsistsOf&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provides a list of nodes for each way of the road network.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Connection&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Contains a list of all connections of the road network including the way it originally is part of. Each connection describes an &lt;em&gt;directed&lt;/em&gt; edge between two junctions in the road network.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ConnectionConsistsOf&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provides a list of nodes each connection consists of.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Restriction&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provides information about turn restrictions. Each turn restriction is described by a from-connection, a via-node, and a to-connection. This data is used for route calculation purposes.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSignals&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Contains  detailed  information  about  traffic  lights and their signalling program. &lt;b&gt;Currently not used&lt;/b&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Route&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Contains a list of all routes known for the simulation scenario. All routes referenced in the &lt;code&gt;Mapping&lt;/code&gt; configuration must be presentin this table.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Building&lt;/code&gt; &lt;br&gt;&lt;code&gt;Corner&lt;/code&gt; &lt;br&gt;&lt;code&gt;Wall&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provides information about buildings alongside the road network, e.g. for visualization purposes or sophisticated communication simulation models.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Version&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Contains the version of the Eclipse MOSAIC installation which was initially used to create the database.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;road-network-model&#34;&gt;Road network model&lt;/h3&gt;
 &lt;p&gt;This section describes the model of the road network used by various components of Eclipse MOSAIC. In the next figure various nodes
 and connections can be seen. A &lt;code&gt;node&lt;/code&gt; is either a junction or describes the geometry of a road. A &lt;code&gt;connection&lt;/code&gt; is a directed edge
 between two junction nodes. That also means, that two separate connections exists for a road segment which can be traversed in both
 directions. Each connection consists of at least two nodes (start and end junction node). Between those nodes, other nodes can exist
 which describe the curvature of the road segment. Furthermore, each connection has a reference to its originating &lt;code&gt;way&lt;/code&gt;, which may
 consist of various connections. A way contains further properties, such as the maximum speed or the type of the road.&lt;/p&gt;


 &lt;figure id=&#34;figure-nodes-and-connections-of-the-road-network&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/node-connections.jpeg&#34; data-caption=&#34;Nodes and connections of the road network&#34;&gt;


   &lt;img src=&#34;../images/node-connections.jpeg&#34; alt=&#34;&#34; width=&#34;50%&#34; &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Nodes and connections of the road network
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Nodes and ways are identified by unique IDs derived from the base OSM network file. Connections, however, are not part of the OSM standard
 and their identifiers are generated during the import. Each connection ID consists of three parts (using the string pattern &lt;code&gt;aaa_bbb_ccc&lt;/code&gt;):&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;aaa&lt;/code&gt; - ID of the originating way&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;bbb&lt;/code&gt; - ID of the node the connection starts at.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;ccc&lt;/code&gt; - ID of the node the connection ends in.&lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-id-of-connection-in-road-network&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/connections.jpeg&#34; data-caption=&#34;ID of connection in road network&#34;&gt;


   &lt;img src=&#34;../images/connections.jpeg&#34; alt=&#34;&#34; width=&#34;50%&#34; &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     ID of connection in road network
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Some components of Eclipse MOSAIC need to identify further parts of the road network, such as one edge between two nodes, or one specific lane of one edge.
 Therefore, the following objects are identified as following:&lt;/p&gt;
 &lt;p&gt;&lt;code&gt;Edges&lt;/code&gt; are described by one start and one end node. The identifier of an edge consists of two parts (using the string pattern &lt;code&gt;aaa_bbb_ccc_ddd&lt;/code&gt;):&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;aaa_bbb_ccc&lt;/code&gt; - ID the connection the edge belongs to.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;ddd&lt;/code&gt; - ID of the node the edge starts at.&lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-structure-of-the-edge-id&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/edges.jpeg&#34; data-caption=&#34;Structure of the Edge-ID&#34;&gt;


   &lt;img src=&#34;../images/edges.jpeg&#34; alt=&#34;&#34; width=&#34;50%&#34; &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Structure of the Edge-ID
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;&lt;code&gt;Lanes&lt;/code&gt; are described by an edge and a lane index. The identifier of a lane consists of two parts (using the string pattern &lt;code&gt;aaa_bbb_ccc_ddd_e&lt;/code&gt;):&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;aaa_bbb_ccc_ddd&lt;/code&gt; - ID the edge the lane belongs to.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;e&lt;/code&gt; - Index of the lane, starting by 0 (leftmost lane).&lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-structure-of-the-lane-id&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/lanes.jpeg&#34; data-caption=&#34;Structure of the Lane-ID&#34;&gt;


   &lt;img src=&#34;../images/lanes.jpeg&#34; alt=&#34;&#34; width=&#34;35%&#34; &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Structure of the Lane-ID
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 </description>
     </item>

     <item>
       <title></title>
       <link>https://www.eclipse.org/mosaic/group/fokus/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/group/fokus/</guid>
       <description></description>
     </item>

     <item>
       <title>File Output Generator</title>
       <link>https://www.eclipse.org/mosaic/docs/visualization/filevis/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/visualization/filevis/</guid>
       <description>&lt;p&gt;The File Output Generator is a tool which gives you the opportunity to log specific Eclipse MOSAIC interaction types. For
 each interaction the File Output receives, one line (or more in case of an iteration object) is added
 to a CSV output file. This allows to track the movements of vehicles or to monitor the V2X message exchange.&lt;/p&gt;
 &lt;p&gt;One example output could be the following:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-csv&#34;&gt;CELL_CONFIGURATION;6000000000;veh_0;true;7200000000;1400000000
 V2X_MESSAGE_TRANSMISSION;6000000000;DENM;3;rsu_0;52.65027;13.545;0.0;CELL_GEOCAST;/255.255.255.255;null
 VEHICLE_UPDATES;7000000000;veh_0;35.501624617716296;186.33236029307432;52.655993308955196;13.569065826100868;0.0;35.501624617716296;-0.6083753822837039;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false
 VEHICLE_REGISTRATION;7000000000;veh_1;ElectricVehicle;null;Unequipped;5.0;2.5;70.0;2.6;4.5;0.5;1.0;1.0;0.0;1;1;0.0
 VEHICLE_UPDATES;8000000000;veh_0;34.978651295430026;186.33236029306624;52.65568017869267;13.569019012494635;0.0;70.48027591314633;-0.5229733222862691;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false
 V2X_MESSAGE_TRANSMISSION;8000000000;DENM;4;rsu_0;52.65027;13.545;0.0;CELL_GEOCAST;/255.255.255.255;null
 VEHICLE_UPDATES;9000000000;veh_0;35.73455352933612;186.33236029306624;52.65536028153272;13.56897118787549;0.0;106.21482944248245;0.7559022339060917;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false
 VEHICLE_UPDATES;9000000000;veh_1;35.52345835176762;186.33265000325784;52.65599046030636;13.569112899208802;0.0;35.52345835176762;-0.5865416482323766;0.0;false;1;4067968_28830219_3290027832_2450938914;1;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h2 id=&#34;configuring-the-fileoutput&#34;&gt;Configuring the FileOutput&lt;/h2&gt;
 &lt;ul&gt;
 &lt;li&gt;The main configuration file is located at &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenarioName&amp;gt;/output/output_config.xml&lt;/code&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;basic-configuration&#34;&gt;Basic configuration&lt;/h4&gt;
 &lt;p&gt;The following listing shows a basic example for the configuration of the FileOutput:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;
 &amp;lt;output id=&amp;quot;fileoutput&amp;quot; enabled=&amp;quot;true&amp;quot; update=&amp;quot;5&amp;quot; loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
 	&amp;lt;filename&amp;gt;output.csv&amp;lt;/filename&amp;gt;
 	&amp;lt;directory&amp;gt;.&amp;lt;/directory&amp;gt;
 	&amp;lt;separator&amp;gt;;&amp;lt;/separator&amp;gt;
 	&amp;lt;subscriptions&amp;gt;
 		&amp;lt;subscription id=&amp;quot;...&amp;quot;&amp;gt;
 		...
 		&amp;lt;/subscription&amp;gt;
 		...
 	&amp;lt;/subscriptions&amp;gt;&amp;gt;
 &amp;lt;/output&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Basic configuration parameters for FileOutput&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;The usage of the parameters is described in the following table:&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Parameter&lt;/th&gt;
 &lt;th&gt;Usage&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;id&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Sets the id for the output&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;enabled&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;If set to &amp;ldquo;false&amp;rdquo;, output is not used (default value is &amp;ldquo;true&amp;rdquo;)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;update&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Sets the update interval in seconds for the output&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;start&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Sets the start time in seconds for output generation. This has nothing to do with the run time of the actual simulation&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;end&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Sets the end time in seconds for output generation. This has nothing to do with the run time of the actual simulation&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;loader&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Sets where the output is loaded from using the Java-class (see previous listing)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;&lt;em&gt;Basic Configuration of file output&lt;/em&gt;&lt;/p&gt;
 &lt;h4 id=&#34;interaction-record&#34;&gt;Interaction record&lt;/h4&gt;
 &lt;p&gt;Each interaction record is derived from a certain interaction type and composed of several entries,which are separated by Element &lt;code&gt;separator&lt;/code&gt;.&lt;/p&gt;
 &lt;p&gt;The configuration of the file output is explained at the example of the &lt;code&gt;VehicleUpdates&lt;/code&gt; interaction:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;subscription id=&amp;quot;VehicleUpdates&amp;quot; enabled=&amp;quot;true&amp;quot;&amp;gt;
 	&amp;lt;entries&amp;gt;
 		&amp;lt;entry&amp;gt;&amp;quot;UPDATE_VEHICLE&amp;quot;&amp;lt;/entry&amp;gt;
 		&amp;lt;entry&amp;gt;Time&amp;lt;/entry&amp;gt;
 		&amp;lt;entry&amp;gt;Updated:Name&amp;lt;/entry&amp;gt;
 		&amp;lt;entry&amp;gt;Updated:Speed&amp;lt;/entry&amp;gt;
 		&amp;lt;entry&amp;gt;Updated:Position.Latitude&amp;lt;/entry&amp;gt;
 		&amp;lt;entry&amp;gt;Updated:Position.Longitude&amp;lt;/entry&amp;gt;
 	&amp;lt;/entries&amp;gt;
 &amp;lt;/subscription&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Specific Configuration for interaction&lt;/em&gt;&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Attribute &lt;code&gt;id&lt;/code&gt; indicates the interaction type, namely the class name of the interaction.&lt;/li&gt;
 &lt;li&gt;The element &lt;code&gt;entries&lt;/code&gt; defines the format and content of the handled subscription record.&lt;/li&gt;
 &lt;li&gt;The element &lt;code&gt;entries&lt;/code&gt; is composed of several sub-elements &lt;code&gt;entry&lt;/code&gt;, which correspond to columns of a subscription
 record and the sequence of the columns is the same as that of sub-elements entry.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;In total, there are three basic types of entries:&lt;/p&gt;
 &lt;h4 id=&#34;constant&#34;&gt;Constant&lt;/h4&gt;
 &lt;p&gt;Every quoted entry is defined as a constant. The content inside the quotation will be directly written
 into each corresponding interaction record.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;&amp;quot;UPDATE_VEHICLE&amp;quot;&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for constant type entry&lt;/em&gt;&lt;/p&gt;
 &lt;h4 id=&#34;basic-method&#34;&gt;Basic method&lt;/h4&gt;
 &lt;p&gt;The Basic method type accesses values of the interaction object by using the appropriate &lt;code&gt;getXXX()&lt;/code&gt; methods. For an entry, the
 root object for method invoking is the corresponding interaction class, here &lt;code&gt;VehicleUpdates&lt;/code&gt;. As this object provides
 the simulation time by calling the getter method &lt;code&gt;getTime()&lt;/code&gt;, the entry &lt;code&gt;Time&lt;/code&gt; retrieves the requested value.
 If a null object is returned before the last method of cascaded methods is invoked, then &lt;code&gt;null&lt;/code&gt; will be written
 to the corresponding field.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Time&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for constant type entry&lt;/em&gt;&lt;/p&gt;
 &lt;h4 id=&#34;iteration&#34;&gt;Iteration&lt;/h4&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Updated:Id&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for method type entry with iteration&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;The first part of this example is &lt;code&gt;Updated&lt;/code&gt; , which means to invoke the getUpdated method of class
 &lt;code&gt;VehicleUpdates&lt;/code&gt;. Then a list of &lt;code&gt;VehicleInfo&lt;/code&gt; objects is returned. The character &lt;code&gt;:&lt;/code&gt; indicates the iteration,
 which means that for each of the &lt;code&gt;VehicleInfo&lt;/code&gt; objects in the returned list the &lt;code&gt;getId&lt;/code&gt; method is invoked.&lt;/p&gt;
 &lt;h4 id=&#34;cascading&#34;&gt;Cascading&lt;/h4&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Updated:Position.Latitude&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for method type entry with iteration and cascading&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;In this example, there is a dot operation, which is a cascade operation. Here &lt;code&gt;getPosition&lt;/code&gt; method of &lt;code&gt;VehicleInfo&lt;/code&gt;
 class is called and a &lt;code&gt;GlobalPosition&lt;/code&gt; object is returned. Then we continuously invoke the &lt;code&gt;getLatitude&lt;/code&gt;
 method of this &lt;code&gt;GlobalPosition&lt;/code&gt; object.&lt;/p&gt;
 &lt;h4 id=&#34;extended-method&#34;&gt;Extended Method&lt;/h4&gt;
 &lt;p&gt;All the methods involved above are the basic methods. There also is some functionality, which we cannot
 extract from these existing methods. So an extended method set is offered to meet these requirements
 and also as an extension point in the future.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;TimeInSec&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for simple extended method type entry&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;With existing methods of &lt;code&gt;VehicleUpdates&lt;/code&gt; and its super class &lt;code&gt;Interaction&lt;/code&gt;, we cannot get the timestamp of
 a interaction in second. (only &lt;code&gt;Interaction.getTime&lt;/code&gt;, which returns a time in ns, is available). Here, &lt;code&gt;getTimeInSec&lt;/code&gt;
 is a method extension for &lt;code&gt;Interaction&lt;/code&gt; class. The extended method set will be listed later.&lt;/p&gt;
 &lt;h2 id=&#34;further-details&#34;&gt;Further details&lt;/h2&gt;
 &lt;p&gt;The method type of entry definition supports cascaded iteration as follows:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;List1:List2:Id&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for cascaded iteration&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;It is possible to handle several different iterating operations, coming from the entry definition:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Senders:Id&amp;lt;/entry&amp;gt;
 &amp;lt;entry&amp;gt;Receivers:Id&amp;lt;/entry&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for multi-level iteration&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;&lt;code&gt;getSenders()&lt;/code&gt; and &lt;code&gt;getReceivers()&lt;/code&gt; are two different iterations. In this case, a combination of both Ids from
 the lists will be generated. The result may look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-csv&#34;&gt;sender1, receiver1
 sender1, receiver2
 sender2, receiver1
 sender2, receiver2
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Output result of the above listing&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;Note: the longest matched prefix will be considered as the same iterating operation, which means they are in the same level of iteration structure.&lt;/p&gt;
 &lt;h2 id=&#34;additional-features&#34;&gt;Additional features&lt;/h2&gt;
 &lt;h4 id=&#34;limit-output-on-time-frame&#34;&gt;Limit output on time frame&lt;/h4&gt;
 &lt;p&gt;You can configure the File Output Generator to write out interactions within a specific frame of simulation time.
 This can be configured by setting the &lt;code&gt;start&lt;/code&gt; and &lt;code&gt;end&lt;/code&gt; attributes accordingly:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;
 &amp;lt;output id=&amp;quot;fileoutput&amp;quot; enabled=&amp;quot;true&amp;quot;
 			start=&amp;quot;300&amp;quot; end=&amp;quot;1000&amp;quot; update=&amp;quot;5&amp;quot;
 			loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
 	...
 &amp;lt;/output&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for restricting output generation of interactions within a time frame&lt;/em&gt;&lt;/p&gt;
 &lt;h4 id=&#34;compress-output&#34;&gt;Compress Output&lt;/h4&gt;
 &lt;p&gt;The tag &lt;code&gt;&amp;lt;write&amp;gt;file+compress&amp;lt;/write&amp;gt;&lt;/code&gt; can be added to the output configuration, in order
 to compress the output using gzip compression. This feature is suitable for large-scale scenarios with
 many outputs.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;output id=&amp;quot;output&amp;quot; loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
 	&amp;lt;write&amp;gt;file+compress&amp;lt;/write&amp;gt;
 	...
 &amp;lt;/output&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 </description>
     </item>

     <item>
       <title>Application Simulator</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/application_simulator/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/application_simulator/</guid>
       <description>&lt;p&gt;This section presents the architecture and the main features of the &lt;strong&gt;Application Simulator&lt;/strong&gt; as well as the related &lt;strong&gt;Mapping&lt;/strong&gt; Ambassador,
 which is used to configure individual simulation entities (or simulation units) and &amp;ldquo;map&amp;rdquo; applications to them.&lt;/p&gt;
 &lt;h2 id=&#34;eclipse-mosaic-application-simulator&#34;&gt;Eclipse MOSAIC Application Simulator&lt;/h2&gt;
 &lt;p&gt;The &lt;strong&gt;Application Simulator&lt;/strong&gt; plays an important role in the simulation of vehicles and its functions. It provides the capability
 to model the application logic for different simulation units (e.g. vehicles, road side units (RSUs), traffic lights, and others)
 as well as possible interaction attempts between the units via different communication links.&lt;/p&gt;
 &lt;h3 id=&#34;folder-structure&#34;&gt;Folder Structure&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    ├─ application
    |  ├─ YourApplication.jar
    |  ├─ application_config.json ............. Configuration file for the ambassador.
    |  └─ &amp;lt;scenario_name&amp;gt;.db .................. Database file for navigation.
    └─ mapping
       └─ mapping_config.json ................. Configuration file for the ambassador.
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This ambassador can be configured with a configuration file. The specific path is
 &lt;code&gt;&amp;lt;scenario_name&amp;gt;/application/application_config.json&lt;/code&gt;. However, it is not necessary to provide such file.&lt;/p&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC installation package.&lt;/p&gt;
 &lt;h3 id=&#34;overview&#34;&gt;Overview&lt;/h3&gt;
 &lt;p&gt;Each simulation unit (e.g. vehicle, RSU, traffic light ..) can have different applications (depending on their application

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/application_simulator/#eclipse-mosaic-mapping&#34;&gt;Mapping&lt;/a&gt;). The applications for the units are basically
 compiled JAVA classes, which &lt;strong&gt;extend&lt;/strong&gt; the abstract class &lt;code&gt;AbstractApplication&lt;/code&gt;. Those classes have to be deployed as pre-compiled
 JAR files into the &lt;code&gt;application&lt;/code&gt; folder of the simulated scenario.&lt;/p&gt;


 &lt;figure id=&#34;figure-overview-of-interaction-between-applications-and-the-units-operating-system-with-its-modules-an-example-v2x-message-propagation-is-presented&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/application_overview.svg&#34; data-caption=&#34;Overview of interaction between applications and the unit&amp;rsquo;s operating system with its modules. An example V2X message propagation is presented.&#34;&gt;


   &lt;img src=&#34;../images/application_overview.svg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     Overview of interaction between applications and the unit&amp;rsquo;s operating system with its modules. An example V2X message propagation is presented.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h4 id=&#34;application-operating-system&#34;&gt;Application Operating System&lt;/h4&gt;
 &lt;p&gt;The &lt;code&gt;AbstractApplication&lt;/code&gt; possesses a unit-specific &lt;code&gt;OperatingSystem&lt;/code&gt;, which allows interactions with the simulated parameters.
 The operating system provides access to information like the current time or position of the units and could control unit-specific
 actions (like &lt;code&gt;slowDown()&lt;/code&gt; for vehicles).&lt;/p&gt;
 &lt;p&gt;As the interaction types for navigation (retrieving road network information and calculating routes) and communication (preparing and
 sending messages) are more complex, they are separated into the specific modules &lt;code&gt;NavigationModule&lt;/code&gt; (Navigation + Routing for
 vehicles) / &lt;code&gt;RoutingModule&lt;/code&gt; (Routing-only for static units) and &lt;code&gt;AdHocModule&lt;/code&gt; / &lt;code&gt;CellModule&lt;/code&gt; with APIs dedicated to their purpose.&lt;/p&gt;
 &lt;p&gt;The following table lists all modules a unit&amp;rsquo;s operating system could provide.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Module&lt;/th&gt;
 &lt;th&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;NavigationModule&lt;/td&gt;
 &lt;td&gt;Full featured access to the central navigation component for vehicles&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;RoutingModule&lt;/td&gt;
 &lt;td&gt;Access to routing functionalities for static units as RSUs&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;AdHocModule&lt;/td&gt;
 &lt;td&gt;Communication via ad hoc mode, using WIFI or ITS G5 specific means (e.g. for addressing)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;CellModule&lt;/td&gt;
 &lt;td&gt;Communication via cellular services (different configuration / addressing modes)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;blockquote&gt;
 &lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; The presented communication modules &lt;code&gt;AdHocModule&lt;/code&gt;, &lt;code&gt;CellModule&lt;/code&gt; are used for the sending part of a transmission. The message
 reception is realized by Application Interfaces provided by the &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;h4 id=&#34;application-interfaces&#34;&gt;Application Interfaces&lt;/h4&gt;
 &lt;p&gt;Application interfaces handle call-backs to incoming events via their methods, like &lt;code&gt;onVehicleUpdated()&lt;/code&gt;, called by the
 application simulator. The following table lists all interfaces usable for application implementation, the type of unit as well as
 important other interfaces it implements. Interface specific public methods which have to be implemented by the user are listed in the
 &amp;ldquo;Provides&amp;rdquo; column. The elementary interface (&lt;code&gt;Application&lt;/code&gt;) provides the methods &lt;code&gt;onStartup()&lt;/code&gt;, &lt;code&gt;onShutdown()&lt;/code&gt;. Implementation details
 are given in
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/&#34;&gt;Development of applications&lt;/a&gt;.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Interface&lt;/th&gt;
 &lt;th&gt;Applicable to&lt;/th&gt;
 &lt;th&gt;Provides&lt;/th&gt;
 &lt;th&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;Application / AbstractApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onStartup&lt;/code&gt;, &lt;code&gt;onShutdown&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Elementary application class providing an operating system&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;ConfigurableApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;td&gt;Basic application class providing an operating system and a configuration, which automatically loaded from a JSON file.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;CommunicationApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onMessageReceived&lt;/code&gt;, &lt;code&gt;onAcknowledgementReceived&lt;/code&gt;, &lt;code&gt;onCamBuilding&lt;/code&gt;, &lt;code&gt;onMessageTransmitted&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;All applications that implement some form of V2X communication are to implement this interface.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;VehicleApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;vehicle&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onVehicleUpdated&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;General vehicle funtionality&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;ElectricVehicleApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;vehicle&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onBatteryStateUpdated&lt;/code&gt;, &lt;code&gt;onChargingRequestRejected&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Electric vehicle functionality&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;TrafficSignAwareApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;vehicle&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onTrafficSignInvalidated&lt;/code&gt;, &lt;code&gt;onTrafficSignNoticed&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Used by vehicles which are aware of traffic signs.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;TrafficLightApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;traffic light&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onTrafficLightGroupUpdated&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Traffic light functionality&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;TrafficManagementCenterApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;TMC&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onInductionLoopUpdated&lt;/code&gt;, &lt;code&gt;onLaneAreaDetectorUpdated&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Traffic management functionality&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;MosaicApplication&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;onSumoTraciResponded&lt;/code&gt;, &lt;code&gt;onInteractionReceived&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Features that involve customized RTI-interactions of MOSAIC&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; A roadside unit (RSU) is the most unit and usually communicates only. Thus, an RSU application implements &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;/p&gt;
 &lt;hr&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;The Application simulator is configured in the file &lt;code&gt;&amp;lt;scenario_name&amp;gt;/application/application_config.json&lt;/code&gt;:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;messageCacheTime&amp;quot;: &amp;quot;30s&amp;quot;,
     &amp;quot;minimalPayloadLength&amp;quot;: 200,
     &amp;quot;encodePayloads&amp;quot;: true,
     &amp;quot;navigationConfiguration&amp;quot; : {
         &amp;quot;type&amp;quot;: &amp;quot;database&amp;quot;
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Furthermore, depending on the deployed applications, the applications itself may offer configuration options
 in custom configuration files (e.g. &lt;code&gt;ETSIApplication.json&lt;/code&gt; or &lt;code&gt;ETSIApplication_veh_0.json&lt;/code&gt;).&lt;/p&gt;
 &lt;hr&gt;
 &lt;h2 id=&#34;eclipse-mosaic-mapping&#34;&gt;Eclipse MOSAIC Mapping&lt;/h2&gt;
 &lt;p&gt;Closely related to the Application Simulator, the &lt;strong&gt;Mapping&lt;/strong&gt; Ambassador is used for the initial choreography of a simulation.
 It defines two major aspects for the simulation units:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;number, properties, position (e.g. of RSUs, traffic lights) or initial routes (of vehicles, simulated in a traffic/vehicle simulator)&lt;/li&gt;
 &lt;li&gt;specific application(s) to be &amp;ldquo;mapped&amp;rdquo; on the simulation units and simulated in the Application Simulation&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;The JSON based configuration is located in &lt;code&gt;&amp;lt;scenario_name&amp;gt;/mapping/mapping_config.json&lt;/code&gt;.&lt;/p&gt;
 &lt;h3 id=&#34;configuration-1&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;The Mapping configuration is divided into different parts:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Pre Definitions of &lt;code&gt;prototypes&lt;/code&gt; and &lt;code&gt;deviations&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Entity Definitions of &lt;code&gt;vehicles&lt;/code&gt;, &lt;code&gt;rsus&lt;/code&gt;, &lt;code&gt;tls&lt;/code&gt; &lt;code&gt;servers&lt;/code&gt; and &lt;code&gt;tmcs&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Advanced Vehicle Definitions (including route generation) in &lt;code&gt;matrixMappers&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Common Definitions in &lt;code&gt;config&lt;/code&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;prototypes&#34;&gt;Prototypes&lt;/h4&gt;
 &lt;p&gt;&lt;code&gt;prototypes&lt;/code&gt; define models for other objects, which can be reused later in the other sections of the Mapping. This allows reusing the
 definition of certain entities such as vehicles or the combination of multiple applications, reducing redundancies and resulting in
 shorter Mapping configurations.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;prototypes&amp;quot;: [
     {
         &amp;quot;name&amp;quot;: &amp;quot;CamVehicle&amp;quot;,
         &amp;quot;accel&amp;quot;: 2.6,
         &amp;quot;decel&amp;quot;: 4.5,
         &amp;quot;length&amp;quot;: 5.00,
         &amp;quot;maxSpeed&amp;quot;: 70.0,
         &amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp&amp;quot; ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Prototypes can be created for all types of entities. Next to the list of &lt;code&gt;applications&lt;/code&gt; which is available for all types of entities,
 vehicle types provide various other parameters to be adjusted.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Parameter&lt;/th&gt;
 &lt;th&gt;Description&lt;/th&gt;
 &lt;th&gt;Deviation&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;vehicleClass&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The class of the vehicle, e.g. &lt;code&gt;Car&lt;/code&gt;, &lt;code&gt;ElectricVehicle&lt;/code&gt;, &lt;code&gt;EmergencyVehicle&lt;/code&gt;, &lt;code&gt;Bicycle&lt;/code&gt;, &lt;code&gt;HeavyGoodsVehicle&lt;/code&gt;, and more.&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;accel&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The maximum acceleration of the vehicle in $m/s^2$.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;decel&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The maximum deceleration of the vehicle in $m/s^2$, e.g. when stopping for traffic lights.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;emergencyDecel&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The maximum deceleration of the vehicle in $m/s^2$, in order to avoid accidents.&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;length&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The length of the vehicle in $m$.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;maxSpeed&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The maximum speed of the vehicle in $m/s$.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;minGap&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The minimum gap towards the leader in $m$, i.e. the space in front in a traffic jam.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;sigma&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The driver&amp;rsquo;s imperfection $[0,1]$.&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;tau&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The reaction time (or time headway) of the vehicle in $s$.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;speedFactor&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;This factor is used to determine the speed limit to comply on roads, e.g. &lt;code&gt;1.1&lt;/code&gt; would exceed the speed limit by 10%.&lt;/td&gt;
 &lt;td&gt;Yes&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;laneChangeMode&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The lane changing behavior of the vehicle: &lt;code&gt;COOPERATIVE&lt;/code&gt;. &lt;code&gt;CAUTIOUS&lt;/code&gt;, &lt;code&gt;AGGRESSIVE&lt;/code&gt;, &lt;code&gt;PASSIVE&lt;/code&gt;, &lt;code&gt;OFF&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;applications&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;The list of applications to map onto this vehicle type.&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;For the majority of the parameters above (see column &amp;ldquo;Deviation&amp;rdquo;), a normal distribution can be created. In that case, each individual
 vehicle spawned with this prototype will be loaded with a random value within this distribution. To achieve this, a separate &lt;code&gt;deviations&lt;/code&gt;
 attribute must be added to the type:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;prototypes&amp;quot;: [
         {
             &amp;quot;name&amp;quot;: &amp;quot;Car&amp;quot;,
             &amp;quot;length&amp;quot;: 5.0,
             &amp;quot;maxSpeed&amp;quot;: 70.0,
             &amp;quot;deviations&amp;quot;: {
                 &amp;quot;length&amp;quot;: 1.2,
                 &amp;quot;maxSpeed&amp;quot;: 5.0
             }
         }
     ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;According to the config above, the basic parameter value conforms to the expected value, and the given value in the &lt;code&gt;deviations&lt;/code&gt;
 attribute conforms to the $\sigma$ of the Gaussian distribution(meaning for the example of maxSpeed that ~68% of the values will
 be located in the interval [65.0, 75.0]). The deviation will be limited to ±2$\sigma$.&lt;/p&gt;
 &lt;h4 id=&#34;entities&#34;&gt;Entities&lt;/h4&gt;
 &lt;p&gt;&lt;strong&gt;Vehicles&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;vehicles&lt;/code&gt;-section is the centerpiece of the Mapping configuration. It defines the departures (times and number),
 routes, and types of the vehicles.&lt;/p&gt;
 &lt;p&gt;Each spawner in this list generates a traffic stream of vehicles on a certain &lt;code&gt;route&lt;/code&gt;. The vehicles stream begins at &lt;code&gt;startingTime&lt;/code&gt; and
 generates vehicles until &lt;code&gt;maxNumberVehicles&lt;/code&gt; is reached. The time between two consecutively vehicles is implicitly given by the
 &lt;code&gt;targetFlow&lt;/code&gt; property, which defines how many vehicles per hour are going to be spawned.&lt;/p&gt;
 &lt;p&gt;Each vehicle spawner must refer to at least one vehicle type (&lt;code&gt;types&lt;/code&gt;). A vehicle type must either refer to a type from the &lt;code&gt;prototypes&lt;/code&gt;
 section by using its &lt;code&gt;name&lt;/code&gt;, or be defined as a completely new vehicle type with all necessary parameters. If more than one vehicle type
 is referenced in the &lt;code&gt;types&lt;/code&gt; attribute, &lt;code&gt;weight&lt;/code&gt;s can be used to specify the ratios to choose between them when loading an individual
 vehicle. If no weights are defined, individual vehicle types are assumed to be distributed equally.&lt;/p&gt;
 &lt;blockquote&gt;
 &lt;p&gt;Note: if at least one vehicle type has a weight defined, all types without a defined weight are ignored.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;vehicles&amp;quot;: [
     {
         &amp;quot;startingTime&amp;quot;: 5.0,
         &amp;quot;targetFlow&amp;quot;: 1800,
         &amp;quot;maxNumberVehicles&amp;quot;: 120,
         &amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
         &amp;quot;types&amp;quot;: [
             {
                 &amp;quot;name&amp;quot;: &amp;quot;CAMVehicle&amp;quot;,
                 &amp;quot;weight&amp;quot;: 0.1
             },
             {
                 &amp;quot;name&amp;quot;: &amp;quot;NormalVehicle&amp;quot;, // this vehicle has no applications
                 &amp;quot;applications&amp;quot;: [ ],
                 &amp;quot;weight&amp;quot;: 0.2
             }
         ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Additional notes:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;The &lt;code&gt;route&lt;/code&gt; refers to a route usually defined in the scenario database file (&lt;code&gt;*.db&lt;/code&gt;) of the scenario.&lt;/li&gt;
 &lt;li&gt;In order to define only one single vehicle to be spawned, the &lt;code&gt;maxNumberVehicles&lt;/code&gt; property can be set to &lt;code&gt;1&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;By defining the &lt;code&gt;endingTime&lt;/code&gt; property, the flow is stopped from being generated when the given simulation time is reached.&lt;/li&gt;
 &lt;li&gt;By defining the &lt;code&gt;spawningMode&lt;/code&gt; to one of the following values, the departure time of the individual vehicles can be adjusted:
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;CONSTANT&lt;/code&gt; - default case, all vehicles have equal time distance to match &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;POISSON&lt;/code&gt; -  vehicles depart within a Poisson distribution, resulting in a more natural traffic flow.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;GROW&lt;/code&gt; - the flow of departing vehicles increases linear up to &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;SHRINK&lt;/code&gt; - the flow of departing vehicles decreases linear starting at &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;GROW_AND_SHRINK&lt;/code&gt; - the flow of departing vehicles increases up to &lt;code&gt;target_flow&lt;/code&gt; and decreases afterwards.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;li&gt;By defining the &lt;code&gt;laneSelectionMode&lt;/code&gt; to one the following values, the selection of the departure lane can be adjusted:
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;DEFAULT&lt;/code&gt; - selects the lane for the next vehicle based on the list of given &lt;code&gt;lanes&lt;/code&gt; in a roundrobin manner.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;ROUNDROBIN_HIGHWAY&lt;/code&gt; - trucks will be spawned on the rightmost lane, all other vehicles according to &lt;code&gt;DEFAULT&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;HIGHWAY&lt;/code&gt; - trucks will be spawned on the rightmost lane, all other vehicles according to &lt;code&gt;BEST&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;RANDOM&lt;/code&gt; - the vehicle will be placed randomly on one of the available lanes of the road.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;FREE&lt;/code&gt; - the vehicle will be placed on a free lane of the road.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;BEST&lt;/code&gt; - the vehicle will be placed on the best lane of the road, according to the current traffic situation and departure speed.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;&lt;strong&gt;Road Side Units&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;rsus&lt;/code&gt;-section offers the possibility to define instances of application supported Road Side Units (RSU)s and place them on a
 defined position (&lt;code&gt;lat&lt;/code&gt;, &lt;code&gt;lon&lt;/code&gt; coordinates). Referring to &lt;code&gt;prototype&lt;/code&gt; definitions with simply specifying its name in the &lt;code&gt;name&lt;/code&gt;
 property will automatically fill in relevant properties of the RSU.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;rsus&amp;quot;: [
     {
         &amp;quot;lat&amp;quot;: 52.65027,
         &amp;quot;lon&amp;quot;: 13.54500,
         &amp;quot;name&amp;quot;: &amp;quot;WeatherServer&amp;quot;,
         &amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.WeatherServerApp&amp;quot; ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Traffic Lights&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;In the &lt;code&gt;trafficLights&lt;/code&gt;-section, applications can be mapped to traffic light groups. Usually, individual traffic lights are part of
 traffic light groups to control a whole junction, whereas the junction possesses a certain position. The traffic light groups and
 their positions are defined in the simulator specific configuration file (e.g. the *.net.xml for SUMO and *.ttl.json for PHABMACS).
 The &lt;code&gt;tlGroupId&lt;/code&gt;-property allows mapping of applications to the traffic light groups, referring them by Id.&lt;/p&gt;
 &lt;p&gt;Alternatively, the definition of the &lt;code&gt;weight&lt;/code&gt;-property leads to a random distribution of the referred applications through ALL traffic lights of the
 scenario (Note: The weights do not have to add up to 100 or 1). Consequently, all traffic lights will be mapped using the specified
 prototypes as soon as one weight differs from zero. So in case you don’t want all traffic lights to have applications running on them you
 have to define one traffic light without any applications and add a weight to it. If neither tlGroupId nor weight are defined for an app, the weight will be set to 1.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;trafficLights&amp;quot;: [
     {
         &amp;quot;tlGroupId&amp;quot;: &amp;quot;26704448&amp;quot;,
         &amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp&amp;quot; ]
     },
     {
         &amp;quot;tlGroupId&amp;quot;: &amp;quot;252864802&amp;quot;,
         &amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp&amp;quot; ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;For more information, explained for detailed examples with different mapping options regarding traffic lights, please refer to

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/#traffic-lights&#34;&gt;Simulation Scenarios - Traffic Lights&lt;/a&gt;.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Servers&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;servers&lt;/code&gt;-array can be used to specify server units, which can be used to communicate with other units via the cell module.
 Capacity configurations for servers should be done when enabling the &lt;code&gt;CellModule&lt;/code&gt;. Delay and transmission models are configured
 in the &lt;code&gt;network.json&lt;/code&gt; of the cell module (see
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_cell/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;
 &lt;blockquote&gt;
 &lt;p&gt;Note: The &lt;code&gt;group&lt;/code&gt; parameter in the mapping configuration has to match with the id in the network configuration in order to
 properly function.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;servers&amp;quot;: [
     {
         &amp;quot;name&amp;quot;: &amp;quot;MyServer&amp;quot;,
         &amp;quot;group&amp;quot;: &amp;quot;TestServers&amp;quot;,
         &amp;quot;applications&amp;quot;: [ &amp;quot;ServerApp1&amp;quot;, &amp;quot;ServerApp2&amp;quot; ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Traffic Management Centers&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;tmc&lt;/code&gt;-section offers the possibility to define instances of a Traffic Management Center (TMC). A TMC
 provides the possibility to interact with the infrastructure of the road, i.e. retrieving traffic properties
 from detectors (e.g. traffic flow), and changing properties from the road (e.g. speed limits).
 Additionally, TMCs are an extension of Servers and can be configured in the same way that servers are&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;tmcs&amp;quot;: [
     {
         &amp;quot;name&amp;quot;: &amp;quot;HighwayManagement&amp;quot;,
         &amp;quot;group&amp;quot;: &amp;quot;TestTmcServers&amp;quot;,
         &amp;quot;applications&amp;quot;: [ &amp;quot;com.dcaiti.vsimrti.app.tutorials.highway.HighwayManagementApp()&amp;quot; ],
         &amp;quot;inductionLoops&amp;quot;: [ &amp;quot;detector_0&amp;quot;, &amp;quot;detector_1&amp;quot;, &amp;quot;detector_2&amp;quot; ],
         &amp;quot;laneAreaDetectors&amp;quot;: [ ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;blockquote&gt;
 &lt;p&gt;All unit spawners could be realized in two different ways. The Deterministic Mapping produces the exact same sequence of mapped vehicles
 in every simulation run with regard to the given ratios at each point in time the simulation).
 The Stochastic Mapping results in a random order of mapped units.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;h4 id=&#34;use-type-distributions-in-complex-traffic-scenarios&#34;&gt;Use Type Distributions in Complex Traffic Scenarios&lt;/h4&gt;
 &lt;p&gt;In the case, you have many vehicle spawners defined and you want to distribute prototypes on those vehicles equally without defining them
 again and again, you can use &lt;code&gt;typeDistributions&lt;/code&gt;. By doing so, it is very simple to adjust the list of types and weights at only one
 place in the configuration file.&lt;/p&gt;
 &lt;p&gt;Instead of defining an equal list of types and weights for each single vehicle spawner, like in this example:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;vehicles&amp;quot;: [
     {
         &amp;quot;startingTime&amp;quot;: 5.0,
         &amp;quot;targetFlow&amp;quot;: 1800,
         &amp;quot;maxNumberVehicles&amp;quot;: 120,
         &amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
         &amp;quot;types&amp;quot;: [
             { &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
             { &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
         ]
     },
     {
         &amp;quot;startingTime&amp;quot;: 55.0,
         &amp;quot;targetFlow&amp;quot;: 1800,
         &amp;quot;maxNumberVehicles&amp;quot;: 120,
         &amp;quot;route&amp;quot;: &amp;quot;2&amp;quot;,
         &amp;quot;types&amp;quot;: [
             { &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
             { &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
         ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&amp;hellip; you can use &lt;code&gt;typeDistributions&lt;/code&gt; to define the distribution of types for each vehicle once and reuse them:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;typeDistributions&amp;quot;: {
     &amp;quot;exampleTypeDist&amp;quot; : [
         { &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
         { &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
     ]
 },
 &amp;quot;vehicles&amp;quot;: [
     {
         &amp;quot;startingTime&amp;quot;: 5.0,
         &amp;quot;targetFlow&amp;quot;: 1800,
         &amp;quot;maxNumberVehicles&amp;quot;: 120,
         &amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
         &amp;quot;typeDistribution&amp;quot;: &amp;quot;exampleTypeDist&amp;quot;
     },
     {
         &amp;quot;startingTime&amp;quot;: 55.0,
         &amp;quot;targetFlow&amp;quot;: 1800,
         &amp;quot;maxNumberVehicles&amp;quot;: 120,
         &amp;quot;route&amp;quot;: &amp;quot;2&amp;quot;,
         &amp;quot;typeDistribution&amp;quot;: &amp;quot;exampleTypeDist&amp;quot;
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h4 id=&#34;advanced-vehicle-spawners-with-route-generation&#34;&gt;Advanced vehicle spawners with route generation&lt;/h4&gt;
 &lt;p&gt;It is also possible to define and use OD (origin-destination) matrices by adding a ODMatrixMapper to the &lt;code&gt;matrixMappers&lt;/code&gt;-list.
 Each MatrixMapper consists of a list of &lt;code&gt;points&lt;/code&gt;, the vehicle-&lt;code&gt;types&lt;/code&gt; to be used and the actual flow-values (&lt;code&gt;odValues&lt;/code&gt;) between each
 of the points. It is possible to define multiple matrices. This way can achieve distinctively different compositions of the vehicle flows.&lt;/p&gt;
 &lt;p&gt;The MatrixMapper will be called before the actual execution of the simulation and will generate vehicle-spawners for the flow between
 each of the points.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;
 &amp;quot;matrixMappers&amp;quot;: [
     {
         &amp;quot;points&amp;quot;: [
             {
                 &amp;quot;name&amp;quot;: &amp;quot;CityA&amp;quot;,
                 &amp;quot;position&amp;quot;: {
                     &amp;quot;center&amp;quot;: {
                         &amp;quot;latitude&amp;quot;: 52,
                         &amp;quot;longitude&amp;quot;: 13
                     },
                     &amp;quot;radius&amp;quot;: 1000
                 }
             },
             {
                 &amp;quot;name&amp;quot;: &amp;quot;CityB&amp;quot;,
                 &amp;quot;position&amp;quot;: {
                     &amp;quot;center&amp;quot;: {
                         &amp;quot;latitude&amp;quot;: 48,
                         &amp;quot;longitude&amp;quot;: 10
                     },
                     &amp;quot;radius&amp;quot;: 1000
                 }
             }
         ],
         &amp;quot;types&amp;quot;: [
             {
                 &amp;quot;name&amp;quot;: &amp;quot;CAMVehicle&amp;quot;
             }
         ],
         &amp;quot;odValues&amp;quot;: [
             [0, 100], //100 vehicles from CityA to CityB
             [200, 0]  //200 vehicles from CityB to CityA
         ]
     }
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h4 id=&#34;common-configuration&#34;&gt;Common Configuration&lt;/h4&gt;
 &lt;p&gt;Next to the specific configuration of prototypes and simulation entities, some general parameters can be adjusted:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;config&amp;quot;: {
         &amp;quot;scaleTraffic&amp;quot; : 1.0,
         &amp;quot;start&amp;quot;: 0,
         &amp;quot;end&amp;quot;: 500,
         &amp;quot;adjustStartingTimes&amp;quot;: false,
         &amp;quot;randomizeFlows&amp;quot;: false,
         &amp;quot;randomizeStartingTimes&amp;quot; : false,
         &amp;quot;randomizeWeights&amp;quot;: false
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Parameter&lt;/th&gt;
 &lt;th&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;scaleTraffic&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Scales the &lt;code&gt;targetFlow&lt;/code&gt; of spawned vehicles per hour as well as the &lt;code&gt;maxNumberVehicles&lt;/code&gt; by the given factor.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;start&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Adjusts the point in time (in $s$) to start spawning vehicles. Any vehicle spawner with a lower &lt;code&gt;startingTime&lt;/code&gt; will be ignored.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;end&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;Adjusts the point in time (in $s$) to end spawning vehicles. Any vehicle spawner with a greater &lt;code&gt;startingTime&lt;/code&gt; will be ignored.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;adjustStartingTimes&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the starting time of each spawner is reduced by the value in &lt;code&gt;start&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;randomizeFlows&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the departure time of vehicles within a vehicle spawner is slightly randomized.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;randomizeStartingTimes&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the starting time of each vehicle spawner is slightly randomized.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;code&gt;randomizeWeights&lt;/code&gt;&lt;/td&gt;
 &lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, each &lt;code&gt;weight&lt;/code&gt; greater than zero is slightly randomized.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;unit-identifiers&#34;&gt;Unit Identifiers&lt;/h3&gt;
 &lt;p&gt;Every traffic object in Eclipse MOSAIC has a globally unique string identifier. These identifiers are used to identify
 a traffic object in Eclipse MOSAIC as well as in different ambassadors. From user’s aspect, these identifiers will be seen in the log files
 which are generated after a simulation. The following table explains, which identifier belongs to which traffic object.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;&lt;strong&gt;Traffic Object&lt;/strong&gt;&lt;/th&gt;
 &lt;th&gt;&lt;strong&gt;Eclipse MOSAIC Internal ID&lt;/strong&gt;&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Vehicle&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;veh_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;rsu_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;TMC&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;tmc_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Traffic Light&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;&lt;code&gt;tl_&amp;lt;group_id&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;seq_nr&lt;/code&gt; is the sequence number of simulated vehicles, RSUs, TMCs, each starting from zero.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;group_id&lt;/code&gt; is the group id of the traffic light.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;hr&gt;
 &lt;p&gt;##Basic Applications&lt;/p&gt;
 &lt;p&gt;Eclipse MOSAIC is shipped with several example applications which can be loaded on the vehicles. Next to the applications shipped with
 the tutorial scenarios &lt;strong&gt;Barnim&lt;/strong&gt; and &lt;strong&gt;Tiergarten&lt;/strong&gt;, there are further example applications to be found on our website.&lt;/p&gt;
 &lt;p&gt;Additionally, we provide an ETSI conform application which implement specific CAM generation rules for vehicles
 (&lt;code&gt;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp&lt;/code&gt;), which is described in the following:&lt;/p&gt;
 &lt;h4 id=&#34;etsi-application-for-vehicles&#34;&gt;ETSI Application for vehicles&lt;/h4&gt;
 &lt;p&gt;This application generates ETSI data for its simulation unit (e.g. heading, position, speed and time for
 vehicles). According to its configuration, the application then sends out CAMs to other vehicles in range.
 Note that the messages are only send when the time lies between the configured minimum and maximum
 interval.&lt;/p&gt;
 &lt;p&gt;Currently, the default configuration (&lt;code&gt;ETSIApplication.json&lt;/code&gt;) for the ETSI application looks like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     /* The maximum time offset (here 1 second) of sending CA-messages
      * (the offset will be different for every single vehicle to avoid interference) */
     &amp;quot;maxStartOffset&amp;quot;: 1000000000,
     /* CAMs are sent at most every 1 second */
     &amp;quot;minInterval&amp;quot;: 100000000,
     /* CAMs are sent at least every 1 second */
     &amp;quot;maxInterval&amp;quot;: 1000000000,
     /* CAMs are sent when the position of the vehicle changes at least about 4 meters */
     &amp;quot;positionChange&amp;quot;: 4,
     /* CAMs are sent when the heading of the vehicle changes at least about 4 degrees */
     &amp;quot;headingChange&amp;quot;: 4,
     /* CAMs are sent when the velocity of the vehicle changes at least about 0.5 m/s */
     &amp;quot;velocityChange&amp;quot;: 0.5
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The CAMs sent out by this application consist of four parts:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Header with generic information&lt;/li&gt;
 &lt;li&gt;MessageBody&lt;/li&gt;
 &lt;li&gt;TaggedValue list&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;First of all, generic information like protocol version and creation time stamp are transmitted. Normally
 this data set follows a network beacon, already containing data like position and speed. Nevertheless
 this functionality must be implemented in the network layer, i.e. in the network simulator. At
 the moment this is not supported and is therefore compensated in the next message part, the message
 body. The body contains vehicle awareness data, including data like vehicle width, length, position, speed, type and heading.
 However, the specification is not completely implemented. Last but not least a message can contain optional data.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Run a simulation with Eclipse MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/docs/getting_started/run_mosaic/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/getting_started/run_mosaic/</guid>
       <description>&lt;p&gt;To run a single simulation via Command Line Interface (CLI), call the Eclipse MOSAIC start script with the
 following command line arguments.&lt;/p&gt;
 &lt;h3 id=&#34;gnulinux&#34;&gt;GNU/Linux&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;./mosaic.sh -s &amp;lt;scenario-name&amp;gt;
 ./mosaic.sh -c ./scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;windows&#34;&gt;Windows&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-dos&#34;&gt;mosaic.bat -s &amp;lt;scenario-name&amp;gt;
 mosaic.bat -c .\scenarios\&amp;lt;scenario_name&amp;gt;\scenario_config.json
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;example&#34;&gt;Example&lt;/h3&gt;
 &lt;p&gt;The following call starts the example scenario &amp;ldquo;Barnim&amp;rdquo; in Eclipse MOSAIC on a Windows machine and opens a
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/visualization/&#34;&gt;Visualization in your browser&lt;/a&gt;:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-dos&#34;&gt;mosaic.bat -s Barnim -v
 &lt;/code&gt;&lt;/pre&gt;


 &lt;figure id=&#34;figure-running-the-pre-bundled-example-scenario-barnim-with-eclipse-mosaic&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/mosaic-barnim.gif&#34; data-caption=&#34;Running the pre-bundled example scenario &amp;ldquo;Barnim&amp;rdquo; with Eclipse MOSAIC&#34;&gt;


   &lt;img src=&#34;../images/mosaic-barnim.gif&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Running the pre-bundled example scenario &amp;ldquo;Barnim&amp;rdquo; with Eclipse MOSAIC
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h3 id=&#34;cli-options&#34;&gt;CLI Options&lt;/h3&gt;
 &lt;p&gt;The Eclipse MOSAIC start script supports the following arguments:&lt;/p&gt;
 &lt;style&gt;
 table th:first-of-type {
     width: 20%;
 }
 table th:nth-of-type(2) {
     width: 80%;
 }
 &lt;/style&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Option&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-c&lt;/code&gt;&lt;br&gt;&lt;code&gt;--configuration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;The primary configuration file which is scenario dependent and located in the according scenario folder. This file transitively includes other necessary configuration files. Usually you will use the file &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-s&lt;/code&gt;&lt;br&gt;&lt;code&gt;--scenario&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;If the main configuration file of your scenario is located in the default scenario directory of MOSAIC (i.e. in &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json&lt;/code&gt;), this option can be used instead of the &lt;code&gt;-c&lt;/code&gt; option by passing only the scenario name &lt;code&gt;-s &amp;lt;scenario_name&amp;gt;&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-w&lt;/code&gt;&lt;br&gt;&lt;code&gt;--watchdog-interval&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;The interval of the internal alive check (in seconds) which is used by MOSAIC to detect execution stalls. This parameter is not mandatory and it is also possible to turn off the watchdog (&lt;code&gt;-w 0&lt;/code&gt;) for debug sessions.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-o&lt;/code&gt;&lt;br&gt;&lt;code&gt;--log-level&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Override all specified logging-levels. This option is useful for debugging simulations. For example logging every possible event would be done with &lt;code&gt;-o TRACE&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-b&lt;/code&gt;&lt;br&gt;&lt;code&gt;--realtime-brake&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;With this parameter, the simulation will be slowed down to a desired Real Time Factor, if possible. When simulations already run slower than real time, this factor will have no effect. For example, use &lt;code&gt;-b 1&lt;/code&gt; to execute the simulation in real time.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-r&lt;/code&gt;&lt;br&gt;&lt;code&gt;--random-seed&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;The global random seed to set for the simulation run. This is usually defined in the &lt;code&gt;scenario_config.json&lt;/code&gt;, but can be overridden using this option.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-v&lt;/code&gt;&lt;br&gt;&lt;code&gt;--start-visualizer&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Opens a page in your default browser which visualizes all vehicle movements of the simulation on a map. This option only works, if your scenario is configured with the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/visualization/&#34;&gt;Websocket Visualizer&lt;/a&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-h&lt;/code&gt;&lt;br&gt;&lt;code&gt;--help&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Prints a help screen.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;While Eclipse MOSAIC is running, it prints some information on the command line:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;[user@gnulinux mosaic]$ ./mosaic.sh -s HelloWorld
 2020-09-08 16:46:09,794 INFO  ROOT - Running Eclipse MOSAIC
 20.0 on Java JRE v1.8.0_202 (AdoptOpenJdk)
 2020-09-08 16:46:09,941 INFO  FederationManagement - Start federation with id &#39;HelloWorld&#39;
 2020-09-08 16:46:09,943 INFO  FederationManagement - Add ambassador/federate with id &#39;application&#39;
 2020-09-08 16:46:09,944 INFO  FederationManagement - Add ambassador/federate with id &#39;mapping&#39;
 2020-09-08 16:46:09,945 INFO  FederationManagement - Add ambassador/federate with id &#39;sumo&#39;
 2020-09-08 16:46:09,946 INFO  FederationManagement - Deploying federate &#39;sumo&#39; locally in .\tmp\sumo
 2020-09-08 16:46:09,962 INFO  FederationManagement - Starting federate &#39;sumo&#39; locally in .\tmp\sumo
 16:46:17 - Simulating: 195000000000ns (195.0s / 1000.0s) - 19.5% (RTF:33.10, ETC:25.2s)
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The current simulation progress is shown in the following format.&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;current wall clock time&lt;/li&gt;
 &lt;li&gt;current simulation time in [ns] and [s]&lt;/li&gt;
 &lt;li&gt;progress in %&lt;/li&gt;
 &lt;li&gt;Real Time Factor (RTF) and Estimated Time to Completion (ETC)&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;The RTF is the ratio of simulated time to simulation duration in wall clock time, e.g. a real time factor
 greater than 1.0 means, the simulation is running faster than real time. Both RTF and ETC are calculated
 based on the performance of the last five seconds of the simulation and should only give a rough overview,
 how long a simulation can take. Depending on the simulation setup, the values can differ heavily between
 start and end of a simulation.&lt;/p&gt;
 &lt;h2 id=&#34;gather-results&#34;&gt;Gather results&lt;/h2&gt;
 &lt;p&gt;All active simulators as well as the according ambassadors generate certain logging output, depending on their configured logging level.
 Therefore, these logs are very helpful to retrace and understand the individual states during the simulation time. The generated log
 files can be found in the &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/logs/log-&amp;lt;timestamp&amp;gt;&lt;/code&gt; directory.&lt;/p&gt;
 &lt;p&gt;Moreover, Eclipse MOSAIC offers uniformly formatted and visually prepared results using various
 &lt;strong&gt;
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/visualization/&#34;&gt;Output Generator&lt;/a&gt;&lt;/strong&gt; implementations. For  example, the &lt;code&gt;FileOutputGenerator&lt;/code&gt; generates
 detailed outputs of e.g. vehicle positions, speeds, or message exchanges.
 In the scenarios brought by the latest release, this output mechanism is already configured.&lt;/p&gt;
 &lt;h2 id=&#34;scenario-configuration&#34;&gt;Scenario Configuration&lt;/h2&gt;
 &lt;p&gt;The configuration of a simulation scenario consists of a detailed description for each coupled simulator. The main configuration file is found under &lt;code&gt;scenario_config.json&lt;/code&gt;,
 which defines the list of coupled simulators:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;simulation&amp;quot;: {
         &amp;quot;id&amp;quot;: &amp;quot;Barnim&amp;quot;,
         &amp;quot;duration&amp;quot;: &amp;quot;1000s&amp;quot;,
         &amp;quot;randomSeed&amp;quot;: 268965854,
         &amp;quot;projection&amp;quot;: {
             &amp;quot;centerCoordinates&amp;quot;: {
                 &amp;quot;latitude&amp;quot;: 52.511289,
                 &amp;quot;longitude&amp;quot;: 13.3167457
             },
             &amp;quot;cartesianOffset&amp;quot;: {
                 &amp;quot;x&amp;quot;: -385769.05,
                 &amp;quot;y&amp;quot;: -5819239.29
             }
         }
     },
     &amp;quot;federates&amp;quot;: {
         &amp;quot;application&amp;quot;: true,
         &amp;quot;environment&amp;quot;: false,
         &amp;quot;cell&amp;quot;: false,
         &amp;quot;ns3&amp;quot;: false,
         &amp;quot;omnetpp&amp;quot;: false,
         &amp;quot;sns&amp;quot;: false,
         &amp;quot;sumo&amp;quot;: true,
         &amp;quot;visualizer&amp;quot;: true
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This way, simulators can be easily added or removed from the simulation. Each of the coupled simulators is configured in the directory
 of the &lt;code&gt;scenario_config.json&lt;/code&gt; file. The release bundle comes with a set of tutorial scenarios, which are described in detail
 in the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/&#34;&gt;Tutorials section&lt;/a&gt;.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Scenario Convert</title>
       <link>https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
   &lt;p&gt;The tool &lt;strong&gt;scenario-convert&lt;/strong&gt; is part of &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
 &lt;p&gt;However, you can use scenario-convert &lt;strong&gt;for free&lt;/strong&gt; to generate scenarios which are executable with Eclipse MOSAIC. &lt;strong&gt;&lt;a href=&#34;https://www.dcaiti.tu-berlin.de/research/simulation/download/&#34; title=&#34;Get it here&#34;&gt;Get it here&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;div style=&#34;text-align: center;&#34;&gt;


 &lt;a class=&#34;mosaic-btn mosaic-btn-primary&#34; href=&#34;https://www.dcaiti.tu-berlin.de/research/simulation/download/&#34; title=&#34;Download scenario-convert from DCAITI mirror&#34;&gt;&lt;i class=&#34;fas fa-download&#34;&gt;&lt;/i&gt;Download scenario-convert from DCAITI mirror&lt;/a&gt;

 &lt;/div&gt;
 &lt;p&gt;&lt;strong&gt;scenario-convert&lt;/strong&gt; is a useful tool, which can be used to create new scenarios or import and export data from
 external sources like OpenStreetMap, SUMO etc into your existing scenarios.&lt;br&gt;
 It will create a database, which is the basis for all map-related tasks performed by Eclipse MOSAIC (e.g. navigation,
 route calculation&amp;hellip;).&lt;br&gt;
 Based on a MOSAIC database, scenario-convert can export the data to SUMO-conform formats.
 Furthermore one can choose, whether to use routes generated by &lt;code&gt;scenario-convert&lt;/code&gt;, use existing
 routes or  build own routes via route generation tools (e.g. DUAROUTER by SUMO).&lt;/p&gt;
 &lt;p&gt;This chapter intends to highlight the most common workflows for the work with &lt;code&gt;scenario-convert&lt;/code&gt;.
 We will be using &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.osm&#34; download&gt;&lt;code&gt;this&lt;/code&gt;&lt;/a&gt; OSM-file for most of the
 use cases So feel free to follow along with the steps to get a better understanding on how the &lt;code&gt;scenario-convert&lt;/code&gt;-script functions.&lt;/p&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;&lt;a href=&#34;#reference-documentation-for-scenario-convert&#34;&gt;Here&lt;/a&gt; you can find a complete reference to all options scenario-convert offers.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;


 &lt;figure id=&#34;figure-osm-file-of-steglitz&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_uncleaned.png&#34; data-caption=&#34;OSM-File of Steglitz&#34;&gt;


   &lt;img src=&#34;../images/osm_uncleaned.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OSM-File of Steglitz
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h2 id=&#34;creating-a-complete-eclipse-mosaic-scenario-from-an-osm-file-with-one-command&#34;&gt;Creating a complete Eclipse MOSAIC-scenario from an OSM-file with one command&lt;/h2&gt;
 &lt;p&gt;This is the most straight forward way to create a scenario from your OSM-file.
 We will use the option &lt;code&gt;--osm2mosaic&lt;/code&gt;, which is a combination of the options &lt;code&gt;--osm2db&lt;/code&gt;
 and &lt;code&gt;--db2mosaic&lt;/code&gt;.&lt;br&gt;
 Let&amp;rsquo;s start off by showing you how a complete call could look like:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm
 &lt;/code&gt;&lt;/pre&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;In this section we use the scenario name &lt;code&gt;steglitz.&lt;em&gt;&lt;/code&gt; as synonym for &lt;code&gt;path/to/steglitz.&lt;/em&gt;&lt;/code&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;This achieves a couple of things. First off the script is going to create a SQLite-database,
 which is used by Eclipse MOSAIC. Furthermore, a directory will be created, which should look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
    └─ steglitz
        ├─ steglitz.osm
        ├─ application
        |  └─ steglitz.db
        ├─ cell
        |  ├─ cell_config.json
        |  ├─ network.json
        |  └─ regions.json
        ├─ environment
        |  └─ environment_config.json
        ├─ mapping
        |  └─ mapping_config.json
        ├─ ns3
        |  ├─ ns3_config.json
        |  └─ ns3_federate_config.xml
        ├─ omnetpp
        |  ├─ omnetpp_config.json
        |  └─ omnetpp.ini
        ├─ output
        |  └─ output_config.xml
        ├─ sns
        |  └─ sns_config.json
        ├─ sumo
        |  ├─ steglitz.net.xml
        |  └─ steglitz.sumocfg
        └─ scenario_config.json .................. Basic configuration of the simulation scenario
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Let&amp;rsquo;s walk through all these files:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;First the &lt;code&gt;steglitz.db&lt;/code&gt; will be created using the &lt;code&gt;steglitz.osm&lt;/code&gt;-file.&lt;/li&gt;
 &lt;li&gt;The &lt;code&gt;steglitz.db&lt;/code&gt; will be used to create &lt;code&gt;steglitz.con.xml&lt;/code&gt;, &lt;code&gt;steglitz.edg.xml&lt;/code&gt; and &lt;code&gt;steglitz.nod.xml&lt;/code&gt;, which are files used by SUMO.&lt;/li&gt;
 &lt;li&gt;
 &lt;a href=&#34;https://sumo.dlr.de/wiki/NETCONVERT&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;SUMO Netconvert&lt;/a&gt; is used to create &lt;code&gt;steglitz.net.xml&lt;/code&gt;, which is a
 &lt;a href=&#34;https://sumo.dlr.de/wiki/Networks/SUMO_Road_Networks&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;network representation&lt;/a&gt; in SUMO.&lt;/li&gt;
 &lt;li&gt;Now the SUMO-configuration &lt;code&gt;steglitz.sumo.cfg&lt;/code&gt; is written.&lt;/li&gt;
 &lt;li&gt;Afterwards the &lt;code&gt;mapping_config.json&lt;/code&gt; and &lt;code&gt;scenario_config.json&lt;/code&gt; are created and all files are moved to the right place.
 In the &lt;code&gt;scenario_config.json&lt;/code&gt; values like the center coordinate will automatically be set using data from the SUMO related files.&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;While this is technically sufficient to start working on your scenario there are a couple of other things
 you can do to achieve better results.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Clean the OSM-file using Osmosis&lt;/strong&gt;&lt;br&gt;
 Osmosis will automatically be used to create a new OSM-file with the suffix &lt;code&gt;_cleaned&lt;/code&gt;. The created
 file will contain much less clutter and usually is better suited for simulation purposes.
 Check the images below to see the difference the clean-up process can make.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm
 &lt;/code&gt;&lt;/pre&gt;
 &lt;div class=&#34;row&#34;&gt;
     &lt;div class=&#34;col-6&#34;&gt;


 &lt;figure id=&#34;figure-uncleaned-osm-file&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_uncleaned.png&#34; data-caption=&#34;Uncleaned OSM-file&#34;&gt;


   &lt;img src=&#34;../images/osm_uncleaned.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Uncleaned OSM-file
   &lt;/figcaption&gt;


 &lt;/figure&gt;

     &lt;/div&gt;
     &lt;div class=&#34;col-6&#34;&gt;


 &lt;figure id=&#34;figure-cleaned-osm-file&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_cleaned.png&#34; data-caption=&#34;Cleaned OSM-file&#34;&gt;


   &lt;img src=&#34;../images/osm_cleaned.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Cleaned OSM-file
   &lt;/figcaption&gt;


 &lt;/figure&gt;

     &lt;/div&gt;
 &lt;/div&gt;
 &lt;div class=&#34;row&#34;&gt;
     &lt;div class=&#34;col-6&#34;&gt;


 &lt;figure id=&#34;figure-uncleaned-net-file&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/netfile_uncleaned.png&#34; data-caption=&#34;Uncleaned Net-file&#34;&gt;


   &lt;img src=&#34;../images/netfile_uncleaned.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Uncleaned Net-file
   &lt;/figcaption&gt;


 &lt;/figure&gt;

     &lt;/div&gt;
     &lt;div class=&#34;col-6&#34;&gt;


 &lt;figure id=&#34;figure-cleaned-net-file&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/netfile_cleaned.png&#34; data-caption=&#34;Cleaned Net-file&#34;&gt;


   &lt;img src=&#34;../images/netfile_cleaned.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Cleaned Net-file
   &lt;/figcaption&gt;


 &lt;/figure&gt;

     &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;To avoid &amp;ldquo;cleaning&amp;rdquo; the OSM-file, please use the option &amp;ldquo;skip-osm-filter&amp;rdquo;.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm --skip-osm-filter
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Generating Routes&lt;/strong&gt;&lt;br&gt;
 The scenario-convert also offers the option &lt;code&gt;--generate-routes&lt;/code&gt;, which will generate
 a route-file, given some additional information. For example purposes we will run the
 following command:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm --generate-routes
 --route-begin-latlon 52.4551693,13.3193474 --route-end-latlon 52.4643101,13.3206834 --number-of-routes 3
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This will calculate three routes between the two given coordinates.&lt;/p&gt;
 &lt;p&gt;Alternatively you can use the following command in order to generate routes with node-id&amp;rsquo;s as start and end point, which can be found in the &lt;code&gt;steglitz.nod.xml&lt;/code&gt; file.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm -o --generate-routes
 --route-begin-node-id 267350668 --route-end-node-id 313139970 --number-of-routes 3
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;See
 &lt;a href=&#34;#reference-documentation-for-scenario-convert&#34;&gt;below&lt;/a&gt; for all command line options.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Conlusion&lt;/strong&gt;&lt;br&gt;
 This wraps up one of the main workflows with the scenario-convert-script.
 A quick reminder on what we achieved:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Cleaned up an OSM-file to only contain relevant data.&lt;/li&gt;
 &lt;li&gt;Converted that OSM-file to formats that Eclipse MOSAIC/SUMO can handle.&lt;/li&gt;
 &lt;li&gt;Created the project structure for a scenario.&lt;/li&gt;
 &lt;li&gt;Calculated routes between two coordinates.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;With all of this you can now start further developing your scenario. For a more detailed description on the next steps
 please have a look
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/&#34;&gt;here (Simulation Scenarios)&lt;/a&gt; and

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/&#34;&gt;here (Application Development)&lt;/a&gt;.&lt;br&gt;
 While this is the &amp;lsquo;happy world&amp;rsquo; workflow it is often necessary to manually adapt routes and
 insert them into your scenario. The following workflow
 will explain how that is done and you will also get a more detailed overview of the scenario-convert-functions.&lt;/p&gt;
 &lt;h2 id=&#34;importing-routes-to-your-scenario&#34;&gt;Importing Routes to your scenario&lt;/h2&gt;
 &lt;p&gt;As mentioned above your routes won&amp;rsquo;t always be created by the scenario-convert script. We generated some routes
 for the steglitz-scenario using SUMO&amp;rsquo;s
 &lt;a href=&#34;http://sumo.dlr.de/wiki/DUAROUTER&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;duarouter&lt;/a&gt;, which you can find

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/files/steglitz.rou.xml&#34;&gt;here&lt;/a&gt;. We&amp;rsquo;ll start with only the &lt;code&gt;steglitz.osm&lt;/code&gt; and
 &lt;code&gt;steglitz.rou.xml&lt;/code&gt; files:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
    ├─ steglitz.osm
    └─ steglitz.rou.xml
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Creating the database&lt;/strong&gt;&lt;br&gt;
 We&amp;rsquo;ll start off by solely creating the database and applying OSMOSIS with the following command:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2db -i steglitz.osm
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The directory should look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
    ├─ steglitz.db
    ├─ steglitz.osm
    ├─ steglitz.rou.xml
    └─ steglitz_cleaned.osm
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Importing the route-file&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;Let&amp;rsquo;s import our routes into the database.&lt;br&gt;
 We achieve this by calling:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;java -jar scenario-convert.jar --sumo2db -i steglitz.rou.xml -d .\steglitz.db
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Now all new routes are imported into our database. The following image shows a visualization of one of
 the created routes.&lt;/p&gt;


 &lt;figure id=&#34;figure-visualization-of-one-of-the-routes&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/steglitz_route.png&#34; data-caption=&#34;Visualization of one of the routes&#34;&gt;


   &lt;img src=&#34;../images/steglitz_route.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Visualization of one of the routes
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;&lt;strong&gt;Creating the scenario&lt;/strong&gt;&lt;br&gt;
 The final step is to create the scenario from the files we created so far.&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;java -jar scenario-convert.jar --db2mosaic -d .\steglitz.db
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Instead of copying our SUMO-files this will generate all necessary files and move them into a Eclipse MOSAIC-conform
 folder structure:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
    ├─ steglitz.osm
    └─ steglitz
       ├─ application
       |  └─ steglitz.db
       ├─ mapping
       |  └─ mapping_config.json
       ├─ sumo
       |  ├─ steglitz.net.xml
       |  └─ steglitz.sumocfg
       └─ scenario_config.json
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;As you can see the resulting folder structure looks just like the final output from the first workflow described.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Conclusion&lt;/strong&gt;&lt;br&gt;
 You should now know how you can manually add routes to your scenario and have a deeper understanding of the way that
 some of the script parameters work.&lt;/p&gt;
 &lt;h3 id=&#34;attached-files&#34;&gt;Attached Files&lt;/h3&gt;
 &lt;p&gt;A list of all attached files in this chapter:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.osm&#34; download&gt;Steglitz OSM-file&lt;/a&gt;&lt;/li&gt;
 &lt;li&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.rou.xml&#34; download&gt;Steglitz Route-file&lt;/a&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h2 id=&#34;reference-documentation-for-scenario-convert&#34;&gt;Reference documentation for scenario-convert&lt;/h2&gt;
 &lt;h3 id=&#34;usage-of-scenario-convert&#34;&gt;Usage of scenario-convert&lt;/h3&gt;
 &lt;p&gt;The following listing shows an overview for the usage of scenario-convert:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;usage: scenario-convert [OPERATION] [OPTIONS]

 Examples:
 1. Import an osm file and write data into database
    &amp;gt; scenario-convert --osm2db -i &amp;lt;OSMFILE&amp;gt; [-d &amp;lt;DATABASE&amp;gt;]
 2. Export database content to SUMO-readable files
    &amp;gt; scenario-convert --db2sumo -d &amp;lt;DATABASE&amp;gt; [-s &amp;lt;SUMOPREFIX&amp;gt;]
 3. Import a SUMO routefile into a database
    &amp;gt; scenario-convert --sumo2db -d &amp;lt;DATABASE&amp;gt; -i &amp;lt;ROUTEFILE&amp;gt;.rou.xml
 4. Combine steps 1 and 2
    &amp;gt; scenario-convert --osm2sumo -d &amp;lt;DATABASE&amp;gt; -i &amp;lt;OSMFILE&amp;gt; [-s &amp;lt;SUMOPREFIX&amp;gt;]
 5. Export db content to Shapefile format
    &amp;gt; scenario-convert --db2shp -d &amp;lt;DATABASE&amp;gt;
 6. Import an srtm file and write elevation data to nodes of an existing database
    &amp;gt; scenario-convert --srtm2db -i &amp;lt;SRTMFILE&amp;gt; -d &amp;lt;DATABASE&amp;gt;
 7. Create a complete MOSAIC scenario from an osm file
    &amp;gt; scenario-convert --osm2mosaic -i &amp;lt;OSMFILE&amp;gt;
 8. Create a scenario database from an SUMO net file
    &amp;gt; scenario-convert --sumo2db -i &amp;lt;NETFILE&amp;gt;.net.xml
 9. Calculate a route from node 123 to node 456
    &amp;gt; scenario-convert --generate-routes -d &amp;lt;DATABASE&amp;gt; --route-begin-node-id 123 --route-end-node-id 456

 The following arguments are available:
  -h,--help                                 Prints this help screen.

  -c,--config-file &amp;lt;PATH&amp;gt;                   Optional, refers to a configuration file which contains all parameters in
                                            JSON format.
     --osm2db                               Converts a OpenStreetMap file to a new scenario database.
     --sumo2db                              Imports a SUMO Network/Routefile. Be aware that you may have to re-export an
                                            imported network.
     --srtm2db                              Imports an SRTM file and writes elevation data to nodes.
     --db2sumo                              Exports the network to SUMO node and edge files.
     --db2shp                               Exports the database into Shapefile format.
     --db2mosaic                            Creates directory structure for a MOSAIC scenario based on the database
                                            contents.
     --osm2sumo                             Combination of osm2db and db2sumo.
     --osm2mosaic                           Combination of osm2db and db2mosaic.
     --update                               Updates the database to the current scheme.

  -d,--database &amp;lt;PATH&amp;gt;                      The path to the database.
                                            For import: File to import to. If not given, a new file is created.
                                            For export: File to load from.
                                            For update operations: file to update.
  -i,--input &amp;lt;PATH&amp;gt;                         Defines an input file to use in an import. File type depends on the import
                                            operation (OSM File/Database file/SUMO net file/SUMO rou file).
  -s,--sumo-prefix &amp;lt;STRING&amp;gt;                 Prefix for the generated sumo files  (uses database name when not defined).
  -f,--force                                Force overwrite of existing files instead of incrementing file names.
  -m,--mapping-file &amp;lt;PATH&amp;gt;                  Uses the given mapping configuration to export existing vehicleTypes and
                                            vehicles data to *.rou.xml.
     --import-lat &amp;lt;DOUBLE&amp;gt;                  Center latitude of imported region to project coordinates.
     --import-lon &amp;lt;DOUBLE&amp;gt;                  Center longitude of imported region to project coordinates.
     --import-zone &amp;lt;STRING&amp;gt;                 UTM zone of location for projecting coords in default format (e.g. 32n).

  -g,--generate-routes                      Generates route(s) from one point to another. The begin and end for the route
                                            must be known (see below options).
     --route-begin-lat &amp;lt;DOUBLE&amp;gt;             Latitude of the starting point, needs --route-begin-lon as well.
     --route-begin-lon &amp;lt;DOUBLE&amp;gt;             Longitude of the starting point, needs --route-begin-lat as well.
     --route-begin-latlon &amp;lt;DOUBLE,DOUBLE&amp;gt;   [latitude],[longitude] of the starting point.
     --route-begin-node-id &amp;lt;STRING&amp;gt;         OSM node id of the starting point (use instead of lat/lon).
     --route-end-lat &amp;lt;DOUBLE&amp;gt;               Latitude of the starting point, needs --route-end-lon as well.
     --route-end-lon &amp;lt;DOUBLE&amp;gt;               Longitude of the starting point, needs --route-end-lat as well.
     --route-end-latlon &amp;lt;DOUBLE,DOUBLE&amp;gt;     [latitude],[longitude] of the ending point.
     --route-end-node-id &amp;lt;STRING&amp;gt;           OSM node id of the ending point (use instead of lat/lon).
     --route-matrix &amp;lt;STRING,STRING,...&amp;gt;     Calculates all possible routes starting and ending at the given nodes, given
                                            as comma-separated list (e.g. 12345,87123,89123)
     --number-of-routes &amp;lt;INTEGER&amp;gt;           Defines the number of alternative routes to be calculated (default=1).

     --skip-osm-filter                      Skips automatic filtering of the OSM file (only with osm2xxx).
     --skip-turn-restrictions               Ignore all defined turn restrictions on OSM import.
     --skip-graph-cleanup                   Turns off the removal of unconnected parts from the main traffic network
                                            graph . Since several components of VSimRTI require one main graph without
                                            disconnected ways and nodes, this option should be used only if the cleanup
                                            procedure is faulty.
     --skip-netconvert                      Skips starting sumo netconvert for creating netfile (only with xxx2sumo).
     --skip-traffic-lights-export           Skips exporting traffic light information for nodes (only with xxx2sumo).
     --osm-speeds-file &amp;lt;PATH&amp;gt;               Define a property file which contains speed information which are used to set
                                            the speed for OSM ways without a max speed tag (only with osm2xxx).
     --osm-speeds-overwrite                 If set to true , the maxspeed tags of ways are ignored and replaced by either
                                            default values , or by speed information defined via the --osm-speeds-file
                                            option (only with osm2xxx).

 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;configuration-files-for-scenario-convert&#34;&gt;Configuration-files for scenario-convert&lt;/h3&gt;
 &lt;p&gt;Scenario-convert offers a way to safe your conversion-parameters in a &lt;code&gt;JSON&lt;/code&gt; configuration file using
 the option &lt;code&gt;-c&lt;/code&gt; or &lt;code&gt;--config-file&lt;/code&gt;.&lt;br&gt;
 The following listing shows how to save the options used in the example above:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;{
   &amp;#34;operatingMode&amp;#34;: &amp;#34;osm2mosaic&amp;#34;,
   &amp;#34;inputFile&amp;#34;: &amp;#34;steglitz.osm&amp;#34;,
   &amp;#34;executeOsmosis&amp;#34;: true,
   &amp;#34;generateRoutes&amp;#34;: true,
   &amp;#34;routeBeginLatLon&amp;#34;: &amp;#34;52.457616,13.318392&amp;#34;,
   &amp;#34;routeEndLatLon&amp;#34;: &amp;#34;52.454774,13.333554&amp;#34;,
   &amp;#34;numberOfRoutes&amp;#34;: 3
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;speed-files&#34;&gt;Speed-files&lt;/h3&gt;
 &lt;p&gt;Below you can find a properties file which can be used during the import of OSM data
 in order to define speeds for ways, which do not have a maxspeeds-tag defined. For this purpose use the
 option &lt;code&gt;--osm-speeds-file &amp;lt;FILE&amp;gt;&lt;/code&gt;. In the speed properties file, for each way type a speed value can
 be defined, according to the OSM
 &lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Key:highway&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;&lt;code&gt;highway&lt;/code&gt;&lt;/a&gt; key.&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;# the unit the speed values are defined in [kmh, ms]
 speed.unit = kmh

 # the default speed for all way types which are not defined here
 speed.default = 30

 # autobahn
 highway.motorway = 130
 highway.motorway_link = 70

 # bundesstrasse (germany)
 highway.trunk = 70
 highway.trunk_link = 65

 # linking bigger town
 highway.primary = 65
 highway.primary_link = 60

 # linking towns &amp;#43; villages
 highway.secondary = 60
 highway.secondary_link = 50

 #streets without middle line separation
 highway.tertiary = 50
 highway.tertiary_link = 40
 highway.residential = 30

 #special roads
 highway.living_street = 5
 highway.service = 20

 # unclassified roads
 highway.unclassified = 30
 highway.road = 20

 # forest tracks
 highway.track 15
 &lt;/code&gt;&lt;/pre&gt;
 </description>
     </item>

     <item>
       <title>Simulation Results</title>
       <link>https://www.eclipse.org/mosaic/docs/getting_started/results/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/getting_started/results/</guid>
       <description>&lt;p&gt;Eclipse MOSAIC generates log files for each simulation run. Log files are generated for the ambassadors of each
 coupled federate respectively simulator and for the RTI itself. The log files are stored in the
 folder &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/logs/log-&amp;lt;timestamp&amp;gt;&lt;/code&gt;. For each simulation run a new folder is created.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ log-&amp;lt;timestamp&amp;gt;
    ├─ apps
    |  └─ &amp;lt;unitType&amp;gt;_&amp;lt;unitId&amp;gt; ................. Detailed application specific logs for each unit
    |      ├─ OperatingSystem.log ............. Detailed operating system logs for the unit
    |      └─ ExampleApp.log .................. Detailed application specific logs for each application.
    ├─ activities.csv ......................... Simulation details in comma separated value-format
    ├─ Application.log  ....................... Information about the application ambassador
    ├─ Cell.log ............................... Cellular network log
    ├─ ChargingStation.log .................... ChargingStation ambassador log
    ├─ Communication.log ...................... (Ad hoc) network simulation ambassador log
    ├─ CommunicationDetails.log ............... Detailed output of network simulator (ns-3 or OMNeT++)
    ├─ Environment.log ........................ Logs of the environmental eventserver
    ├─ Mapping.log ............................ Mapping configuration logs
    ├─ MOSAIC.log ............................. General information, e.g. startup sequence information
    ├─ Navigation.log ......................... Detailed logs about navigation component in the application ambassador
    ├─ Traffic.log ............................ Traffic simulation log (SUMO or others)
    └─ output.csv ............................. Recorded data of the integrated File Output Generator
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;In addition to standard logging output for each federate there is a &lt;code&gt;activities.csv&lt;/code&gt; file which contains
 detailed information about sent and received interactions. This file can be used to trace a
 simulation run for deep debugging. To enable this feature, the log level of the logger &lt;code&gt;activities&lt;/code&gt; has to be
 set to &lt;code&gt;INFO&lt;/code&gt; in the &lt;code&gt;logback.xml&lt;/code&gt; (see section below).&lt;/p&gt;
 &lt;h2 id=&#34;logging&#34;&gt;Logging&lt;/h2&gt;
 &lt;p&gt;The main configuration file for logging is &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/etc/logback.xml&lt;/code&gt;. In this file, the log output
 can be configured in great detail. This file can be adjusted to your needs, e.g. you can set up a more detailed logging
 for communication components but set a less verbose output for Eclipse MOSAIC&amp;rsquo;s internal interactions or traffic
 simulation depending on your simulation focus.&lt;/p&gt;
 &lt;p&gt;Eclipse MOSAIC uses &lt;em&gt;LOGback&lt;/em&gt; as logging framework. &lt;em&gt;LOGback&lt;/em&gt; offers a lot of parameters to adapt the output to your needs. Please refer to

 &lt;a href=&#34;https://logback.qos.ch/manual/layouts.html#ClassicPatternLayout&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;this site&lt;/a&gt; for a detailed overview of all
 parameters you can use in the &lt;code&gt;logback.xml&lt;/code&gt; file.&lt;/p&gt;
 &lt;p&gt;Please note that you can adjust the output to your needs by setting different log levels (&lt;code&gt;ERROR&lt;/code&gt;, &lt;code&gt;INFO&lt;/code&gt;,
 &lt;code&gt;DEBUG&lt;/code&gt; etc.) for each component in the file at &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/etc/logback.xml&lt;/code&gt;. This might also influence
 the simulation performance because of a possibly high amount of data to be logged.&lt;/p&gt;
 &lt;h3 id=&#34;federate-specific-logging&#34;&gt;Federate specific logging&lt;/h3&gt;
 &lt;p&gt;Depending on the simulation purpose, further configuration possibilities for federate specific logging
 may be of interest.&lt;/p&gt;
 &lt;p&gt;For instance, OMNeT++ exhibits an elaborated logging concept. The &lt;code&gt;omnetpp.ini&lt;/code&gt; in the scenario folder
 includes options to adjust the logging levels. The outputs of this federate are written to &lt;code&gt;CommunicationDetails.log&lt;/code&gt;.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Simulator Coupling</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/simulator_coupling/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/simulator_coupling/</guid>
       <description>&lt;p&gt;This section provides general information which helps to couple your own simulator with Eclipse MOSAIC. For a
 successful coupling, two parts are required: the Federate Ambassador is the communication interface
 between the RTI and your simulator. It implements predefined interfaces of the Eclipse MOSAIC core library
 and is directly coupled with Eclipse MOSAIC. Second, your simulator needs to communicate with the Federate
 Ambassador. For this purpose, you either need to implement your own protocol to control the simulator,
 or use existing ones of your respective simulator (e.g. SUMO provides the TraCI byte buffer protocol).&lt;/p&gt;
 &lt;hr&gt;
 &lt;h2 id=&#34;implementing-a-federate-ambassador&#34;&gt;Implementing a Federate Ambassador&lt;/h2&gt;
 &lt;p&gt;In order to simplify federate development and to make the usage of the mechanisms provided by the RTI
 safer, an abstract class called &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt; is provided by the Eclipse MOSAIC core package.
 It implements the &lt;code&gt;FederateAmbassador&lt;/code&gt; interface and handles incoming interactions as well as time
 advance grants according to the specified federate behaviour. When a federate implementation is making
 use of the &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt; as a super class, it has to provide two information to the
 superclass while constructing an instance of the class. These are:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;isTimeConstrained&lt;/code&gt;: The general way this parameter can be understood, is that if it is set to &lt;strong&gt;true&lt;/strong&gt;
 the federate is sensitive towards the time stamp order of interactions. The &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
 will then queue incoming interactions and request a time advance from the RTI in order to ensure that
 processing the received interaction is safe. At the time the requested time advance is granted, every
 queued interaction with a time stamp smaller or equal to the granted time will be delivered to the
 federate for processing. If set to &lt;strong&gt;false&lt;/strong&gt;, incoming interactions will be forwarded immediately to
 the federate, thus resulting in a &lt;em&gt;receive-order&lt;/em&gt; of interactions at the federate.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;isTimeRegulating&lt;/code&gt;: Specifies whether the federate will publish time stamped interactions and
 thus can influence the time advances of other federates in the federation. If set to &lt;strong&gt;true&lt;/strong&gt;, the &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
 will request time advances with respect to the specified lookahead
 value of the federate in order to avoid that time management schedules the execution of other
 federates while queued interactions are processed. If set to &lt;strong&gt;false&lt;/strong&gt;, time advance requests that are
 issued due to incoming interactions will be flagged with an unlimited lookahead, allowing the RTI to
 schedule other federates while incoming interactions are processed.&lt;/p&gt;
 &lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-flowchart-of-interaction-handling&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/flowchart_timeconstrained_timeregulating.png&#34; data-caption=&#34;Flowchart of Interaction handling&#34;&gt;


   &lt;img src=&#34;../images/flowchart_timeconstrained_timeregulating.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Flowchart of Interaction handling
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h3 id=&#34;further-notes&#34;&gt;Further notes&lt;/h3&gt;
 &lt;p&gt;Coupling a multitude of different simulators and properly syncing them is a non-trivial task and requires a lot of effort in order to
 function correctly. If you have read up on High Level Architecture before
 (have a look
 &lt;a href=&#34;https://en.wikipedia.org/wiki/High_Level_Architecture&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;here&lt;/a&gt; and at the linked references) you might notice, that the
 previous flowchart does not completely reflect the proposed mechanisms. For instance, the &lt;code&gt;isTimeRegulating&lt;/code&gt; flag has no effect, when the
 &lt;code&gt;isTimeConstrained&lt;/code&gt; flag is not set.&lt;br&gt;
 So at some points you might stumble upon federates, which have their &lt;code&gt;isTimeConstrained&lt;/code&gt; and &lt;code&gt;isTimeRegulating&lt;/code&gt; flags set to different
 values as you would expect. An example of this is the &lt;code&gt;ApplicationAmbassador&lt;/code&gt;. One would expect it to be time-constrained as well as
 time-regulating. This isn&amp;rsquo;t the case though, because the &lt;code&gt;ApplicationAmbassador&lt;/code&gt; implements its own time- and event-management,
 which would interfere with the internal mechanisms.&lt;br&gt;
 When implementing your own federate, you can use the existing ones as reference.&lt;/p&gt;
 &lt;h3 id=&#34;example&#34;&gt;Example&lt;/h3&gt;
 &lt;p&gt;A federate that is &lt;code&gt;timeConstrained&lt;/code&gt; and &lt;code&gt;timeRegulated&lt;/code&gt; can handle a time stamped interaction
 only after receiving a corresponding time advance grant. For that reason, the &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
 caches the incoming interactions in a local queue and requests a time advance with the interactions
 time stamp. After getting a grant for that time stamp, it forwards the interaction via the &lt;code&gt;processInteraction&lt;/code&gt;
 method call and afterwards invokes &lt;code&gt;processTimeAdvanceGrant&lt;/code&gt; to allow the federate to proceed in its
 local simulation time. In the activity diagram in the following figure, the process of handling of incoming interactions
 with respect to the federate configuration is illustrated.&lt;/p&gt;


 &lt;figure id=&#34;figure-sequence-diagram-illustrating-the-flow-of-information&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/federate-sequence.jpeg&#34; data-caption=&#34;Sequence diagram illustrating the flow of information.&#34;&gt;


   &lt;img src=&#34;../images/federate-sequence.jpeg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Sequence diagram illustrating the flow of information.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h3 id=&#34;integration-into-eclipse-mosaic&#34;&gt;Integration into Eclipse MOSAIC&lt;/h3&gt;
 &lt;p&gt;The first step to integrate a new component is the extension of the configuration file &lt;code&gt;etc/runtime.json&lt;/code&gt;.
 An example for a federate configuration can be found in following listing.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: [
     ...
     {
         &amp;quot;id&amp;quot;: &amp;quot;omnetpp&amp;quot;,
         &amp;quot;classname&amp;quot;: &amp;quot;org.eclipse.mosaic.fed.omnetpp.ambassador.OmnetppAmbassador&amp;quot;,
         &amp;quot;configuration&amp;quot;: &amp;quot;omnetpp_config.json&amp;quot;,
         &amp;quot;configurationDeployPath&amp;quot;: &amp;quot;omnetpp-federate/simulations&amp;quot;,
         &amp;quot;priority&amp;quot;: 50,
         &amp;quot;dockerImage&amp;quot;: &amp;quot;&amp;quot;,
         &amp;quot;host&amp;quot;: &amp;quot;local&amp;quot;,
         &amp;quot;port&amp;quot;: 4998,
         &amp;quot;deploy&amp;quot;: true,
         &amp;quot;start&amp;quot;: true,
         &amp;quot;subscriptions&amp;quot;: [
             &amp;quot;VehicleRegistration&amp;quot;,
             &amp;quot;RsuRegistration&amp;quot;,
             &amp;quot;TrafficLightRegistration&amp;quot;,
             ...
         ],
         &amp;quot;javaClasspathEntries&amp;quot;: []
     },
     ...
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The following parameters are available:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;class&lt;/code&gt; - Attribute giving the full qualified name of the Java class which implements the Feder-
 ateAmbassador interface.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;id&lt;/code&gt; - The id of the federate. This value should be as short as possible and will be also used for
 identifying the configuration folder within scenarios.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;deploy&lt;/code&gt; - If set to true, the federate placed under bin/fed/&lt;id&gt; will be copied to the execution
 host (according to the host configuration file).&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;start&lt;/code&gt; - If set to true, the federate will be started by the federation management using the start
 command specified in the configuration file or this implementation.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;subscriptions&lt;/code&gt; - A list of interaction names which the Federate Ambassador subscribes for. If any other
 ambassador sends out one of those interactions, this ambassador will receive them.&lt;/p&gt;
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;hr&gt;
 &lt;h2 id=&#34;interaction-extension&#34;&gt;Interaction extension&lt;/h2&gt;
 &lt;p&gt;Another possibility to extend Eclipse MOSAIC is to add a new interaction to the set of predefined interactions. In the following
 figure, the abstract class &lt;code&gt;Interaction&lt;/code&gt;, implemented interaction extensions, and a place holder for further
 extensions (rectangles with grey fonts and a dotted border) are illustrated. When the InteractionManagement
 forwards interactions among federates, it chooses the destination based on a interaction id and
 an optional condition. Furthermore, it synchronizes the interaction delivery based on their times. The
 abstract class &lt;code&gt;Interaction&lt;/code&gt; offers these attributes but no further content. The exchanged content has to be
 implemented by extending the class &lt;code&gt;Interaction&lt;/code&gt;. The already implemented extensions cover the content
 necessary to simulate common scenarios. However, for further scenarios further interactions might be
 required.&lt;/p&gt;


 &lt;figure id=&#34;figure-interaction-classes-and-their-relationships&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/mosaic-message-classes.png&#34; data-caption=&#34;Interaction classes and their relationships..&#34;&gt;


   &lt;img src=&#34;../images/mosaic-message-classes.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Interaction classes and their relationships..
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 </description>
     </item>

     <item>
       <title></title>
       <link>https://www.eclipse.org/mosaic/group/dcaiti/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/group/dcaiti/</guid>
       <description></description>
     </item>

     <item>
       <title>Eclipse SUMO - Simulation of Urban MObility</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/traffic_simulator_sumo/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/traffic_simulator_sumo/</guid>
       <description>&lt;p&gt;&lt;strong&gt;Eclipse SUMO&lt;/strong&gt; is an highly portable, microscopic and continuous road traffic
 simulation tool. It is designed to handle large road networks faster than real-time and simulates each vehicle
 individually.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Operating System&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;GNU/Linux and Microsoft Windows&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;License&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;EPL-2.0&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Website&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;
 &lt;a href=&#34;https://www.eclipse.org/sumo/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://www.eclipse.org/sumo/&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Supported versions&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;Recommended version:&lt;br&gt;Full support:&lt;br&gt;Limited support:&lt;/td&gt;
 &lt;td&gt;
 1.8.0&lt;br&gt;
 1.2.0 - 1.8.0&lt;br&gt;
 1.0.1, 1.1.0&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;td&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;


 &lt;a class=&#34;mosaic-btn mosaic-btn-primary&#34; href=&#34;https://sumo.dlr.de/wiki/Downloads&#34; title=&#34;Download Eclipse SUMO&#34;&gt;&lt;i class=&#34;fas fa-external-link-alt&#34;&gt;&lt;/i&gt;Download Eclipse SUMO&lt;/a&gt;

 &lt;p&gt;Download the SUMO binary bundle or installer from the SUMO website. Linux users may build SUMO from the source code.
 Please refer to the SUMO Wiki for further information.&lt;/p&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;In order to run SUMO with Eclipse MOSAIC you need to make the SUMO binaries available system wide by adding the SUMO
 binary folder to your &lt;code&gt;PATH&lt;/code&gt; environment variable. Alternatively, the environment variable &lt;code&gt;SUMO_HOME&lt;/code&gt; can be used to
 define the installation directory of SUMO.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;div class=&#34;alert alert-tip&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;We recommend using the 64 bit version of SUMO if you want to simulate scenarios with a big traffic network.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;This ambassador can be configured with a configuration file. The specific path is &lt;code&gt;&amp;lt;scenarioName&amp;gt;/sumo/sumo_config.json&lt;/code&gt;.
 If no such file exists, the following default configuration options are used:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
 	&amp;quot;updateInterval&amp;quot;: 1000,
 	&amp;quot;sumoConfigurationFile&amp;quot;: &amp;quot;&amp;lt;scenarioName&amp;gt;.sumo.cfg&amp;quot;,
 	&amp;quot;exitOnInsertionError&amp;quot;: true,
 	&amp;quot;additionalSumoParameters&amp;quot;: &amp;quot;--time-to-teleport 0  --seed 100000&amp;quot;,
 	&amp;quot;subscriptions&amp;quot;: [ &amp;quot;roadposition&amp;quot;, &amp;quot;signals&amp;quot;, &amp;quot;emissions&amp;quot; ],
     &amp;quot;subscribeToAllVehicles&amp;quot;: true
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Next to &lt;code&gt;sumo_config.json&lt;/code&gt;, the following configuration files are required for every SUMO simulation scenario:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ sumo
       ├─ &amp;lt;scenarioName&amp;gt;.net.xml .............. SUMO Network file
       ├─ &amp;lt;scenarioName&amp;gt;.rou.xml .............. SUMO Route file
       ├─ &amp;lt;scenarioName&amp;gt;.sumocfg .............. SUMO configuration file
       └─ sumo_config.json .................... Ambassador configuraition file]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The SUMO configuration consists of sumo specific config files and the sumo-ambassador configuration
 file. The main configuration file name must end with the suffix *.cfg, which needs to refer to the network and route
 files. The network file is mandatory and should be generated with the &lt;code&gt;scenario-convert&lt;/code&gt; tool provided with Eclipse
 MOSAIC.&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;&amp;lt;scenarioName&amp;gt;.rou.xml&lt;/code&gt; is optional and is generated automatically for each simulation run. The routes for each
 vehicle are then usualy taken from the scenario database. However, those routes can be overriden by defining them
 manually in the route file.&lt;/p&gt;
 &lt;div class=&#34;alert alert-warning&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;&lt;strong&gt;Eclipse MOSAIC ignores SUMOs *.rou.xml files&lt;/strong&gt;&lt;br&gt;
 With Eclipse MOSAIC, the traffic definition (definition of vehicles, flows, vehicle types) is part of the Mapping
 configuration file. Any vehicles or flows defined within the &lt;code&gt;&amp;lt;scenarioName&amp;gt;.rou.xml&lt;/code&gt; are ignored and won’t be simulated
 by SUMO.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;Vehicle related parameters, such as acceleration, maximum speed, and the like, are configured via the Mapping
 configuration file. However, some SUMO specific parameters, like the car following model, needs to be configured
 separately in the route file. For example, if you have configured a vehicle type called &lt;code&gt;MyVehicle&lt;/code&gt; in the Mapping
 configuration, you can set specific parameters for this type in the &lt;code&gt;&amp;lt;scenarioName&amp;gt;.rou.xml&lt;/code&gt; as following:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;routes&amp;gt;
     &amp;lt;vType id=&amp;quot;MyVehicle&amp;quot; carFollowModel=&amp;quot;IDM&amp;quot; lcKeepRight=&amp;quot;10&amp;quot;&amp;gt;
 &amp;lt;/routes&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Further information about SUMO and its configuration can be found in the official SUMO wiki.&lt;/p&gt;
 &lt;h3 id=&#34;using-the-sumo-gui-with-eclipse-mosaic&#34;&gt;Using the SUMO GUI with Eclipse MOSAIC&lt;/h3&gt;
 &lt;p&gt;It is also possible to use the graphical interface of SUMO in order to visualize and interact with the simulation. To
 achieve this, Eclipse MOSAIC can be configured to start the GUI process of SUMO as the federate rather than the command
 line interface. In order to use the SUMO GUI the file &lt;code&gt;&amp;lt;mosaic&amp;gt;/etc/runtime.json&lt;/code&gt; needs to be edited. Here, the entry
 &lt;code&gt;org.eclipse.mosaic.fed.sumo.ambassador.SumoAmbassador&lt;/code&gt; must be replaced with
 &lt;code&gt;org.eclipse.mosaic.fed.sumo.ambassador.SumoGuiAmbassador&lt;/code&gt;.&lt;/p&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;Keep in mind to launch Eclipse MOSAIC with the argument &lt;code&gt;-w 0&lt;/code&gt; in order to disable the watchdog timer. Otherwise, it
 would shut down Eclipse MOSAIC if the simulation is paused in the SUMO GUI.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 </description>
     </item>

     <item>
       <title>Interactions in Eclipse MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/interactions/</link>
       <pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/interactions/</guid>
       <description>&lt;p&gt;This chapter is intended to document interactions that can be sent and received between Eclipse MOSAIC federates
 in order to enable users to easily design and integrate new federates and connect them to existing
 federates. Note that we use the word &amp;ldquo;interaction&amp;rdquo; whenever we describe communication between federates,
 whereas we talk about a &amp;ldquo;message&amp;rdquo; primarily when concerned with V2X-communication.&lt;/p&gt;
 &lt;p&gt;All interactions are categorized by the package they are contained in, which corresponds to their main context/purpose.
 The &amp;ldquo;Sent by&amp;rdquo; column is not necessarily complete for all interactions but should give an idea where interactions are used.&lt;/p&gt;
 &lt;h2 id=&#34;mapping&#34;&gt;mapping&lt;/h2&gt;
 &lt;p&gt;All interactions in this package are concerned with adding/registering simulation-units to the simulation.
 While most of the introductions are handled by the &lt;code&gt;Mapping&lt;/code&gt;- or &lt;code&gt;Application&lt;/code&gt;-ambassador, some of them
 are handled by the ambassadors for the traffic simulators (see
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/lust/&#34;&gt;LuST&lt;/a&gt;-scenario).
 In this case the interactions are used to initialize the scenario.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is sent by the vehicle mapping component to indicate the introduction of a new vehicle to the simulation. Note, this does not necessarily imply that the added vehicle is already simulated by the traffic simulator.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;br&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStationRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a charging station to the simulation. All units are introduced at simulation start time, e.g. 0s.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;RsuRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a roadside unit to the simulation.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TmcRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a traffic management center to the simulation. It holds a list of all applications and all induction loops and lane are detectors the TMC is responsible for.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ServerRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a server to the simulation. It holds a list of all applications.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping3&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficLightRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a traffic light (group) to the simulation. It holds a traffic light group, which unites all traffic light signals used for one traffic light system.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSignRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction indicates the introduction of a traffic sign.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;mappingadvanced&#34;&gt;mapping.advanced&lt;/h3&gt;
 &lt;p&gt;Interactions in this package are still concerned with the mapping of vehicles but differ from simple simulation unit registration.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ScenarioTrafficLightRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction contains the phases and their duration of each traffic light in the simulation. This interaction shall be generated by the traffic simulators at start up (e.g. SUMO)&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo&lt;/code&gt;&lt;br&gt;&lt;code&gt;Phabmacs&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ScenarioVehicleRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to add vehicles to a simulation using a preconfigured scenario, which could be defined by using Sumo.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo(Scenario)&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;RoutelessVehicleRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is sent the vehicle mapping component to indicate the introduction of a new vehicle whose route is not yet known. This interaction is usually handled by the &lt;code&gt;Application&lt;/code&gt;-ambassador, which calculates a route for the given vehicle and sends out an VehicleRegistration-interaction afterwards.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;communication&#34;&gt;communication&lt;/h2&gt;
 &lt;p&gt;This package contains interactions regarding the setup of communication-components in simulation units and interactions concerned with the transfer of V2X-messages.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;AdHocCommunicationConfiguration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to exchange information about the configuration of a vehicle’s ad-hoc communication facilities.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;CellularCommunicationConfiguration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to exchange information about the configuration of a vehicle’s cellular communication facilities.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;Interactions related to V2X-message transfer.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;V2xMessageAcknowledgement&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used by a communication simulator to inform about success or failure of a packet transmission. Typically, the application simulator should subscribe to this interaction.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Cell&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;V2xMessageReception&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to exchange information about a received V2X message.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Omnet++&lt;/code&gt;&lt;br&gt;&lt;code&gt;ns-3&lt;/code&gt;&lt;br&gt;&lt;code&gt;SimpleNetworkSimulator&lt;/code&gt;&lt;br&gt;&lt;code&gt;cell&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;V2xFullMessageReception&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction carries the payload that represents an arbitrary V2XMessage that is supposed to be received by the receiver of this Eclipse MOSAIC Interaction.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Omnet++&lt;/code&gt;&lt;br&gt;&lt;code&gt;ns-3&lt;/code&gt;&lt;br&gt;&lt;code&gt;SimpleNetworkSimulator&lt;/code&gt;&lt;br&gt;&lt;code&gt;Cell&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;V2xMessageRemoval&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to exchange information about  V2X messages, that are to be deleted.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;V2xMessageTransmission&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is sent in order to trigger the transportation of a V2XMessage over a wireless network to a given geographical destination area.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;vehicle&#34;&gt;vehicle&lt;/h2&gt;
 &lt;p&gt;The interactions contained in this package are usually used to enable applications to forward vehicle-control to the used traffic simulators.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleActuatorsChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to directly control the throttle/brake of an vehicle. At the moment this is only supported by Phabmacs.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleDistanceSensorActivation&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to enable the distance sensors of a vehicle. A multitude of sensors can be enabled with one interaction given they use the same maximum lookahead distance.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleFederateAssignment&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used, when more than one traffic simulator is used in a simulation. It enables the passing of information on which vehicle are passed externally. At the moment this is used by the PhSCA-ambassador.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;PhaSCA&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleLaneChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction initiates a lane change for the given vehicle, which should be consumed by the traffic simulators.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleParametersChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction requests to update various parameters of the vehicle or its driver.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleResume&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction requests the given vehicle to continue its journey after being stopped beforehand. The interaction should be handled by traffic simulators&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleRouteChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to change a route for vehicle by its id. It can be assumed that the given route id has been propagated by either a VehicleRoutesInitialization- or VehicleRouteRegistration-interaction.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleRouteRegistration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to propagate a newly generated route which is not yet known. It consists of the id of the route and a list of all its edges.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleSightDistanceConfiguration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to configure the sight distance for a vehicle (driver), this information can for example be used to implement applications regarding traffic sign recognition.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleSlowDown&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction initiates the vehicle to slow down in a given interval. The request should be handled by traffic simulators. The name &amp;lsquo;SlowDown&amp;rsquo; is inherited by Sumo and a little bit misleading, the speed can also be increased.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleSpeedChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction sets the current speed of the given vehicle. This should be handled by traffic simulators&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleStop&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction requests the given vehicle to stop at the given road position, it should be handled by traffic simulators.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;traffic&#34;&gt;traffic&lt;/h2&gt;
 &lt;p&gt;Interactions in this package are focused around traffic management and communication with traffic simulators.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;CellularHandoverUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used by the cell ambassador to communicate handovers.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;cell&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;InductionLoopDetectorSubscription&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction subscribes a unit to the data of an induction loop detector, usually this will be TMCs. In order to retrieve the data, traffic simulators have to be told to omit the subscribed data.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;LaneAreaDetectorSubscription&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction subscribes a unit to the data of a lane area detector, usually this will be TMCs. In order to retrieve the data, traffic simulators have to be told to omit the subscribed data.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;LanePropertyChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction contains lane properties to be changed. Concretely, it sets a list of allowed and disallowed vehicle classes per lane and a new maximum speed limit that shall be changed. The changed lane properties have to be omitted to the traffic simulator to be handled.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficDetectorUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This extension of {@link Interaction} combines updates of lane area and induction loop detectors.  Usually the updates are supplied by the traffic simulator and will be filtered by applications subscribed to them.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficLightStateChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to forward a request to change the state of a simulated traffic light. This interaction can be used to implement different controlling strategies for traffic lights.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficLightUpdate&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is a container for traffic light update. It is sent by the SumoAmbassador to inform simulation units about an updated traffic light state.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to update the position of some or all vehicles of the simulation. It consists of three lists, containing newly added vehicles, vehicles which were updated since the last simulation step, and vehicles which have been removed from the traffic simulation.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo&lt;/code&gt;&lt;br&gt;&lt;code&gt;Phabmacs&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleTypesInitialization&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;This interaction is required for each simulation.&lt;/strong&gt; It contains predefined vehicle types. Other ambassadors may cache this interaction in order to have access on vehicle types, which are later identified by their identifier.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Mapping&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleRoutesInitialization&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;This interaction is required for each simulation.&lt;/strong&gt; It contains all routes vehicles will take during the simulation. Other ambassadors may cache this interaction in order to have access on the routes, which are later identified by their identifier.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;electricity&#34;&gt;electricity&lt;/h2&gt;
 &lt;p&gt;All interactions contained in this package are related to electric vehicles and the surrounding infrastructure.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingDenialResponse&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is sent out by the charging station ambassador to inform the application simulator (the vehicles) when a charging station is already in use. e.g. a vehicle wants to start charging on an engaged charging station -&amp;gt; ChargingStartDenial.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStation&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStartResponse&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to forward a started charging process at a ChargingSpot to the RTI.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStation&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStationUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This extension interaction is intended to be used to forward the updated state of a ChargingStation to the RTI.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStation&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStopResponse&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to forward a stopped charging process at a charging station to the RTI.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ChargingStation&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleChargingStartRequest&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to forward a request from a vehicle to &lt;strong&gt;start&lt;/strong&gt; charging its battery at a charging station to the RTI.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleChargingStopRequest&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to forward a request from a vehicle to &lt;strong&gt;stop&lt;/strong&gt; charging its battery at a charging station to the RTI.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleElectricityUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to inform the applications of simulation units about changed electric information, send out by the battery ambassador.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Battery&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;environment&#34;&gt;environment&lt;/h2&gt;
 &lt;p&gt;The interactions in this package are used for handling the communication about environment sensors.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;EnvironmentSensorActivation&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to signal interest in sensor information for a specific simulation unit.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;EnvironmentSensorUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used to exchange sensor data.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;EventServer&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;GlobalEnvironmentUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This extension of interaction contains a list of current environment events and their locations. Those events can than be used to react upon a changing environment.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;EventServer&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;trafficsigns&#34;&gt;trafficsigns&lt;/h2&gt;
 &lt;p&gt;Interactions in this package are used to communicate changes in variable traffic signs, e.g. changing the speed limit.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;AbstractTrafficSignChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction can be sent to traffic sign ambassador in order to change a variable traffic sign. All interaction-classes, that are concerned with changing traffic signs extend this class.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSignLaneAssignmentChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction can be sent to traffic sign ambassador in order to change a variable lane assignment sign.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSignSpeedLimitChange&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction can be sent to traffic sign ambassador in order to change a variable speed sign.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleSeenTrafficSingsUpdate&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction stores a map of all traffic signs which are in sight distance of a specific vehicle and a map of all  traffic signs which became invalid for that vehicle.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSign&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h2 id=&#34;application&#34;&gt;application&lt;/h2&gt;
 &lt;p&gt;Interactions in this package are used for applications. They are used to communicate custom information/data via the RTI.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Interaction name&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Sent by&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ApplicationInteraction&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is intended to be used in custom applications, it can be extended for simulation units to react upon different influences and can be used for intercommunication between applications.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ItefLogging&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to exchange log-tuples for the ITEF (Integrated Testing and Evaluation Framework).&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;SumoTraciRequest&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction is used to send a byte array message to SUMO TraCI. The request will be handled by TraCI and trigger a SumoTraciResponse.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Application&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;SumoTraciResponse&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This interaction holds the TraCI response for a SumoTraciRequest. It is sent by the SumoAmbassador and will usually be handled by the Application that sent the request.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Sumo&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 </description>
     </item>

     <item>
       <title>Additional Scenario Configuration</title>
       <link>https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_configuration/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_configuration/</guid>
       <description>&lt;p&gt;This chapter aims to give you a brief overview of additional simulators and visualizers that can be used with Eclipse MOSAIC.
 We will continue with the tutorial-style explanations following up on the Steglitz-example from the

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/&#34;&gt;previous chapter&lt;/a&gt;. For more detailed explanations of the configurations have a
 look at
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/&#34;&gt;this chapter&lt;/a&gt;.&lt;br&gt;
 If you already played with the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/barnim_basic/&#34;&gt;Barnim&lt;/a&gt;-tutorial you probably noticed, that it contains far
 more folders in the scenario structure compared to the Steglitz example. Those additional directories contain
 configurations for various simulators.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ Barnim
    ├─ application
    ├─ cell
    ├─ environment
    ├─ mapping
    ├─ ns3
    ├─ output
    ├─ sns
    ├─ sumo
    └─ scenario_config.json .................. Basic configuration of the simulation scenario
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h2 id=&#34;let-the-cars-loose&#34;&gt;Let the cars loose&lt;/h2&gt;
 &lt;p&gt;As a starting point we&amp;rsquo;ll look at the scenario that we created using this command:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm -o --generate-routes
 --route-begin-latlon 52.4551693,13.3193474 --route-end-latlon 52.4643101,13.3206834 --number-of-routes 3
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;We&amp;rsquo;ll end up with a folder looking like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ steglitz
    ├─ application
    |  └─ steglitz.db
    ├─ mapping
    |  └─ mapping_config.json
    ├─ sumo
    |  ├─ steglitz.net.xml
    |  └─ steglitz.sumocfg
    └─ scenario_config.json .................. Basic configuration of the simulation scenario
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;If you have a look in the &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz_mapping_config.json&#34; download&gt;&lt;code&gt;mapping_config.json&lt;/code&gt;&lt;/a&gt;,
 you can see that the scenario-convert script automatically assigns cars to the three routes created. You can use this
 file as a blueprint for your own scenario, have a look
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/#applications-and-mapping&#34;&gt;here&lt;/a&gt;
 to get more details on possible adaptions.&lt;br&gt;
 Below is a short video of the scenario displayed in the SUMO-GUI. We marked the three different routes the cars
 follow.&lt;/p&gt;


 &lt;video controls &gt;
   &lt;source src=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/images/steglitz_routes.mp4&#34; type=&#34;video/mp4&#34;&gt;
 &lt;/video&gt;
 &lt;h2 id=&#34;communication-simulators-cell-ns3-omnetpp-sns&#34;&gt;Communication Simulators (cell, ns3, omnetpp, sns)&lt;/h2&gt;
 &lt;p&gt;We won&amp;rsquo;t implement any functionality for the steglitz example here but rather have a look at the

 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/barnim_basic/&#34;&gt;Barnim&lt;/a&gt;-tutorial. In the &lt;code&gt;scenario_config.json&lt;/code&gt; of the Barnim scenario you can see where the
 communication simulators are activated:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: {
     &amp;quot;cell&amp;quot;: false,
     &amp;quot;omnetpp&amp;quot;: false,
     &amp;quot;ns3&amp;quot;: false,
     &amp;quot;sns&amp;quot;: true
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Our
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/&#34;&gt;tutorials&lt;/a&gt; and
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/additional_examples/&#34;&gt;additional examples&lt;/a&gt; demonstrate use cases for
 communication usages and you should have a look at them if you are uncertain where to start. Furthermore we
 recommend copying the configuration-files for the simulator you are going to use from the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/tutorials/barnim_basic/&#34;&gt;Barnim scenario&lt;/a&gt;. It
 contains the most complete configurations and is well maintained.&lt;br&gt;
 If you are an expert with one of the external network simulators (
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/&#34;&gt;ns3&lt;/a&gt;,

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/&#34;&gt;OMNeT++&lt;/a&gt;) the Barnim scenario will also give
 you an overview on how to configure those.&lt;/p&gt;
 &lt;h2 id=&#34;other-simulators&#34;&gt;Other Simulators&lt;/h2&gt;
 &lt;p&gt;Here we&amp;rsquo;ll discuss two simulators integrated with Eclipse MOSAIC and their use-cases, namely the &lt;code&gt;Event Server&lt;/code&gt; and the
 &lt;code&gt;Battery Simulator&lt;/code&gt;.&lt;/p&gt;
 &lt;h3 id=&#34;event-server&#34;&gt;Event server&lt;/h3&gt;
 &lt;p&gt;The event server can be used to emit events to vehicles inside it&amp;rsquo;s predefined borders. In the Barnim scenario
 an event server is used to simulate an icy area, which is then noticed by the sensor of a weather server RSU.&lt;br&gt;
 Every defined event requires a type, a defined geographical area (e.g. circular, rectangular), the strength and a time frame. Have a look
 at the &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/eventserver_config.json&#34; download&gt;&lt;code&gt;eventserver_config.json&lt;/code&gt;&lt;/a&gt; to see how this can be
 configured. If you want to use the event server make sure to have it enabled in the &lt;code&gt;scenario_config.json&lt;/code&gt;.&lt;/p&gt;
 &lt;h3 id=&#34;battery&#34;&gt;Battery&lt;/h3&gt;
 &lt;p&gt;The battery simulator is used to simulate electric vehicles. It offers a lot of customization, because you can
 dynamically load your own battery, vehicle and environment models. Have a look a the &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/battery_config.json&#34; download&gt;&lt;code&gt;battery_config.json&lt;/code&gt;&lt;/a&gt;, taken from the Barnim scenario.
 The three models used are included with Eclipse MOSAIC and you can freely use them.&lt;/p&gt;
 &lt;h2 id=&#34;output&#34;&gt;Output&lt;/h2&gt;
 &lt;p&gt;There are various options to generate output results of your simulations (see the

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/visualization/filevis/&#34;&gt;visualization chapter&lt;/a&gt;).&lt;/p&gt;
 &lt;p&gt;The first step is to create a file called &lt;code&gt;output_config.xml&lt;/code&gt; in a new directory called &lt;code&gt;output&lt;/code&gt;.
 If you used the scenario-convert tool the file should be generated automatically.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ steglitz
    ├─ application
    |  └─ steglitz.db
    ├─ mapping
    |  └─ mapping_config.json
    ├─ output
    |  └─ output_config.xml
    ├─ sumo
    |  ├─ steglitz.net.xml
    |  └─ steglitz.sumocfg
    └─ scenario_config.json .................. Basic configuration of the simulation scenario
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Example configuration for output generation can be taken from the example scenarios from the tutorials section.&lt;/p&gt;
 &lt;!--
 Next make sure the visualization federate is activated in the `scenario_config.json`.
 ```
 &lt;!-- Visualization --&gt;
 &lt;federate id=&#34;output&#34; active=&#34;true&#34;/&gt;
 ```
 Now we have to configure the statistics visualizer itself. This &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz_visualizer_config.xml&#34; download&gt;`visualizer_config.xml`&lt;/a&gt; contains the basic
 configuration in order to calculate the average travel times for the vehicles. If you want to make adaptions, please
 refer to [statistics visualizer](/docs/visualization/statistics).
 Go ahead and run the simulation one more time. Afterwards the log-directory should contain a file called
 `AverageVehicleTravelTime.csv` in a directory called `StatisticsVisualizer`:
 ```
 group;group-value;total;
 Car;186.369;336;
 ```
 This tells us that there was a total amount of 336 vehicles of the type `car` in the simulation, which traveled
 for 186.369  seconds on average.--&gt;
 &lt;p&gt;&lt;strong&gt;Conclusion&lt;/strong&gt;&lt;br&gt;
 After this small, hands-on introduction to visualizers you should know where to configure them and after some additional
 reading, you should be able to configure different types of visualizers for your use-cases.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Statistics Output</title>
       <link>https://www.eclipse.org/mosaic/docs/visualization/statistics/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/visualization/statistics/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
 &lt;p&gt;The &lt;strong&gt;Statistics Output Generator&lt;/strong&gt; is part of &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;&lt;/strong&gt;.&lt;br&gt;
 For further information on licenses, feel free to contact us via &lt;strong&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;mosaic@fokus.fraunhofer.de&lt;/a&gt;&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;Statistics Output is another output generating tool to easily measure basic simulation outcomes.
 You will be able to obtain short or detailed results of the simulation, e.g. travel times or the average speeds
 of groups of vehicles, or the average flow on induction loops.&lt;/p&gt;
 &lt;h2 id=&#34;configuration&#34;&gt;Configuration&lt;/h2&gt;
 &lt;ul&gt;
 &lt;li&gt;The main configuration file for all output generators is located at &lt;code&gt;&amp;lt;scenarioName&amp;gt;/output/output_config.xml&lt;/code&gt;&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;In order to use the Statistics Output, the attribute &lt;code&gt;enabled&lt;/code&gt; of the root element &lt;code&gt;output&lt;/code&gt; must be
 set to &amp;ldquo;true&amp;rdquo;, as shown in the following listing.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;output id=&amp;quot;statistics&amp;quot; enabled=&amp;quot;true&amp;quot; loader=&amp;quot;com.dcaiti.mosaic.fed.visualizer.StatisticsVisualizerConfig&amp;quot;&amp;gt;
 	[..]
 &amp;lt;/output&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Configuration header for Statistics Output&lt;/em&gt;&lt;/p&gt;
 &lt;h2 id=&#34;specification&#34;&gt;Specification&lt;/h2&gt;
 &lt;p&gt;In this section, we take a closer look at the Statistics Output by using examples and demonstrations. For
 each type of retrieving data we create a &lt;code&gt;&amp;lt;statistic&amp;gt;&amp;lt;/statistic&amp;gt;&lt;/code&gt; block. Inside the block we define
 one certain data type we want to retrieve in a &lt;source&gt; element. If you want to retrieve different data
 types, just create another &lt;code&gt;&amp;lt;statistic&amp;gt;&lt;/code&gt; block for each of them.&lt;/p&gt;
 &lt;p&gt;You can also set the wanted file name in the attribute filename of the statistic element. If the
 attribute has not been given, each &lt;code&gt;&amp;lt;statistic&amp;gt;&lt;/code&gt; block will get the name accordingly to the order number,
 for example &lt;code&gt;1. StatisticsVisualizer-Block.csv&lt;/code&gt;.&lt;/p&gt;
 &lt;p&gt;In the output attribute two options (&lt;code&gt;short&lt;/code&gt;|&lt;code&gt;verbose&lt;/code&gt;) can be selected. The short option provides us
 a compact log file with information about only the highest level of the retrieved data (e.g. aggregate
 values of grouped vehicles) in contrast to verbose option which also provides informations about every
 individual vehicle in each group.&lt;/p&gt;
 &lt;p&gt;For a successful start, the element source must be placed in the first position in the &lt;code&gt;statistic&lt;/code&gt; children
 element list. Different options of possible data types, one of which must be specified in the source
 element can be seen below.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;statistic filename=&amp;quot;ChooseItYourself&amp;quot; output=&amp;quot;short&amp;quot;&amp;gt;
 	&amp;lt;source&amp;gt;NameOfSource&amp;lt;/source&amp;gt;
 &amp;lt;/statistic&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Source options of Statistics Output&lt;/em&gt;&lt;/p&gt;
 &lt;h2 id=&#34;application&#34;&gt;Application&lt;/h2&gt;
 &lt;p&gt;This section will demonstrate the basic idea and usage of the Statistics Output depending on the
 individual requirements. Next to retrieving raw data, the Statistics Output has further features for
 processing of the obtained data.&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;&lt;code&gt;source&lt;/code&gt;: Data to obtain, choose between:
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;VehicleSpeeds&lt;/code&gt; - Obtain the speeds of the vehicles of each simulation step.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleStops&lt;/code&gt; - The total number of stops during the journey of each vehicle.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleTravelTimes&lt;/code&gt; - The total travel time in s of the vehicles.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleDelayTimes&lt;/code&gt; - The deviation of the travel time compared to the fastest travel time possible for the vehicles (in s).&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleTravelledDistances&lt;/code&gt; - The travelled distance of the vehicles in m.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleFuelConsumptions&lt;/code&gt; - The fuel consumptions of the vehicles in l per km.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;VehicleHeadways&lt;/code&gt; - Obtain the headway towards the leading vehicle of each vehicle for each simulation step. To obtain this value, an application has to be deployed on the vehicles which activates the front distance sensor.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;DetectorFlow&lt;/code&gt; - The flows of each subscribed induction loop.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;For using the detector flow type, inductions loops need to be configured in the SUMO and mapping configuration files (e.g. Highway tutorial).&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;ol start=&#34;2&#34;&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;group-by&lt;/code&gt;: The vehicles will be grouped by its vehicle type name (&lt;code&gt;VehicleType&lt;/code&gt;), group they belong
 to (&lt;code&gt;VehicleGroup&lt;/code&gt;), or obtained data value (e.g. &lt;code&gt;Interval:200&lt;/code&gt; categorizes values into groups of
 size 200).&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;aggregation&lt;/code&gt;: &lt;code&gt;Average&lt;/code&gt; | &lt;code&gt;Harmonic&lt;/code&gt; aggregation of the obtained values. An attribute &lt;code&gt;deviation&lt;/code&gt;
 can be set to true or false (it’s false if the attribute is not given). This attribute can be used for
 grouped values to get the deviation of each value from the aggregated group value or to get a
 standard deviation based on biased sample variance for groups (in the short output version).&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;&lt;code&gt;filter&lt;/code&gt;: Filtering with the attribute &lt;code&gt;filterType&lt;/code&gt; (possible values are &lt;code&gt;keep&lt;/code&gt; and &lt;code&gt;remove&lt;/code&gt;).&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Filtering by required value slots with two options to specify them: &lt;code&gt;MoreThan:Value&lt;/code&gt; or &lt;code&gt;LessThan:Value&lt;/code&gt; (e.g. &lt;code&gt;MoreThan:5&lt;/code&gt; to collect values which are bigger than 5 only)&lt;/li&gt;
 &lt;li&gt;Filtering by vehicle type. &lt;code&gt;VehicleType:Type&lt;/code&gt; (e.g. &lt;code&gt;VehicleType:Car&lt;/code&gt; to collect values only of vehicles of type &amp;ldquo;Car&amp;rdquo;)&lt;/li&gt;
 &lt;li&gt;Filtering by time. &lt;code&gt;Time:From-To&lt;/code&gt; (e.g. &lt;code&gt;Time:0-100&lt;/code&gt; to collect values only of the first 100s of simulation time)&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;The following example will show an example of how you can specify the Statictics Output according to
 your desired criteria. VehicleTravelTimes are the data we want to retrieve from vehicles and we want
 to group vehicles by the abstract group we can define in mapping configuration file (see e.g. Barnim
 scenario) and then calculate the average vehicle travel time value for each of these groups.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;output id=&amp;quot;statistics&amp;quot; enabled=&amp;quot;true&amp;quot; loader=&amp;quot;com.dcaiti.mosaic.fed.visualizer.StatisticsVisualizerConfig&amp;quot;&amp;gt;
 	&amp;lt;statistic filename=&amp;quot;AverageVehicleTravelTimes&amp;quot; output=&amp;quot;short&amp;quot;&amp;gt;
 		&amp;lt;source&amp;gt;VehicleTravelTimes&amp;lt;/source&amp;gt;
 		&amp;lt;group-by&amp;gt;VehicleGroup&amp;lt;/group-by&amp;gt;
 		&amp;lt;aggregation&amp;gt;Average&amp;lt;/aggregation&amp;gt;
 	&amp;lt;/statistic&amp;gt;
 &amp;lt;/output&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;Getting the Average time by vehicle class&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;You can also combine filters if you want to get a certain interval with upper and lower boundaries. With
 the following input instruction, only vehicles with the obtained data values between 250 and 500 will be
 left after filtering.&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;filter filterType=&amp;quot;keep&amp;quot;&amp;gt;LessThan:500&amp;lt;/filter&amp;gt;
 &amp;lt;filter filterType=&amp;quot;remove&amp;quot;&amp;gt;LessThan:250&amp;lt;/filter&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;An example for filtering&lt;/em&gt;&lt;/p&gt;
 &lt;p&gt;Please notice that some sources are being not only obtained in each simulation step but also collected for
 further processing as separate values for each of these steps (like &lt;code&gt;VehicleSpeeds&lt;/code&gt;, &lt;code&gt;VehicleHeadways&lt;/code&gt;).
 These data types need to be aggregated to one value per vehicle if you want to group them by value or
 filter them.&lt;/p&gt;
 &lt;p&gt;For demonstration, the Statistics Output is configured for the scenario Barnim and calculates the
 average travel times of the vehicles and additionally groups them. As a result, the simulation produces
 the following CSV file in the log directory:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-csv&#34;&gt;Group;Value;Total;
 AdHoc;399.14;24;
 Cellular;463.87;12;
 Unequipped;459.18;84;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;em&gt;The AverageVehicleTravelTime.csv file produced by the Statistics Output in the Barnim scenario&lt;/em&gt;&lt;/p&gt;
 </description>
     </item>

     <item>
       <title></title>
       <link>https://www.eclipse.org/mosaic/group/openmobility/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/group/openmobility/</guid>
       <description></description>
     </item>

     <item>
       <title>Application Ambassador - Implementation Details</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/application_ambassador_details/</link>
       <pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/application_ambassador_details/</guid>
       <description>&lt;p&gt;The Application Simulator is completely implemented as an Eclipse MOSAIC Ambassador in Java. The main class &lt;code&gt;ApplicationAmbassador&lt;/code&gt; is
 started by the RTI and creates different components, like the &lt;code&gt;SimulationKernel&lt;/code&gt; singleton or the &lt;code&gt;CentralNavigationComponent&lt;/code&gt;.
 Subsequently, it will find all the Java Archive (JAR) files in the &lt;code&gt;application&lt;/code&gt; configuration directory, belonging to the currently started
 scenario, and add their classes to the class path. These JARs contain the application classes. Furthermore, the ApplicationAmbassador is
 registered as a handle for different Eclipse MOSAIC messages in the configuration file &lt;code&gt;etc/runtime.json&lt;/code&gt; in the Eclipse MOSAIC folder. After
 initialization, the Application Simulator will receive these messages from Eclipse MOSAIC when they appear and perform corresponding actions.&lt;/p&gt;
 &lt;h3 id=&#34;node-creation&#34;&gt;Node Creation&lt;/h3&gt;


 &lt;figure id=&#34;figure-application-simulator-basic-flow--node-creation-classes&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/class_overview.png&#34; data-caption=&#34;Application Simulator basic flow / node creation classes&#34;&gt;


   &lt;img src=&#34;../images/class_overview.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Application Simulator basic flow / node creation classes
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Application classes are only instantiated when a node, carrying that application, is created. This is signaled by messages for node creation
 like (&lt;code&gt;AddedVehicle,AddedRsu,AddedTrafficLight&lt;/code&gt;, &amp;hellip;). When the &lt;code&gt;Mapping&lt;/code&gt; ambassador spawns a new node, it will send those messages to the
 RTI. The message then contains the fully qualified names of all applications associated with the spawned node, as well as the vehicle type
 itself.  Depending on this type, the Application Simulator creates a new &lt;code&gt;SimulationUnit&lt;/code&gt; object (i.e. a subclass of &lt;code&gt;SimulationUnit&lt;/code&gt; like
 &lt;code&gt;Vehicle&lt;/code&gt;, &lt;code&gt;RoadSideUnit&lt;/code&gt; or &lt;code&gt;TrafficLight&lt;/code&gt;), representing the new node. This task is served by the &lt;code&gt;UnitSimulatorclass&lt;/code&gt;, which performs
 book keeping of all &lt;code&gt;SimulationUnits&lt;/code&gt;. Upon Creation of a node, the &lt;code&gt;UnitSimulator&lt;/code&gt; will schedule an event to start all applications,
 belonging to the new node. The required information is saved in a &lt;code&gt;StartApplications&lt;/code&gt; object, which also includes a &lt;code&gt;ApplicationUnit&lt;/code&gt;
 object, an abstract representation of a node (a.k.a. unit) having at least one application.&lt;/p&gt;
 &lt;p&gt;However, as, for example, SUMO does not simulate vehicles strictly from their creation on, but only since their first movement, Applications
 for vehicles cannot be started directly upon an &lt;code&gt;AddedVehicle&lt;/code&gt; message. Instead, every added vehicle will be kept in the &lt;code&gt;addedVehicles&lt;/code&gt;
 Map, until a &lt;code&gt;VehicleMovements&lt;/code&gt; message, belonging to that vehicle is processed. The vehicle will then be added by the &lt;code&gt;UnitSimulator&lt;/code&gt;
 like any other node.&lt;/p&gt;
 &lt;h3 id=&#34;other-messages-and-time-advance&#34;&gt;Other Messages and Time Advance&lt;/h3&gt;
 &lt;p&gt;Apart from the ones for node creation, there are many other messages (see
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/extending_mosaic/interactions/&#34;&gt;Interactions&lt;/a&gt;),
 signaling events to the Application Simulator. For most of them, an event in the future will be programmed, such that the implied action is
 carried out at that simulation time. The processing of the events happens when the RTI calls the &lt;code&gt;advanceTime()&lt;/code&gt; method on the ambassador.
 Upon this, Application Simulator will obtain a list of all events up to the new time and let the processor of the event process them. Every
 potential event processor implements the &lt;code&gt;EventProcessor&lt;/code&gt; interface. The corresponding method is the &lt;code&gt;advanceTime()&lt;/code&gt; method of
 &lt;code&gt;ApplicationAmbassador&lt;/code&gt;, which calls &lt;code&gt;scheduleEvents()&lt;/code&gt; on the event scheduler. Subsequently, some interesting messages and their
 handling process is sketched shortly:&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Message&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;VehicleUpdates&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Signals that a vehicle has moved.  The &lt;code&gt;Vehicle&lt;/code&gt; object, which is a subclass of &lt;code&gt;SimulationUnit&lt;/code&gt;, that corresponds to the moved vehicle will be updated to contain the new position. The new information is encapsulated in a &lt;code&gt;VehicleInfo&lt;/code&gt; object, containing different vehicle data. To update the data, an event is scheduled at the given time and processed upon time advance. Vehicles not yet added to the simulation (see
 &lt;a href=&#34;#node-creation&#34;&gt;Node Creation&lt;/a&gt;), are added by calling &lt;code&gt;addVehicleIfNotYetAdded()&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;MessageReceiption&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This message represents the reception of a V2X-message by a simulated node. The &lt;code&gt;SimulationUnit&lt;/code&gt; with the id saved in the &lt;code&gt;ReceivedV2XMessage&lt;/code&gt; object is scheduled for the processing of the message at the given simulation time. When simulation time reaches the reception time, the &lt;code&gt;SimulationUnit&lt;/code&gt; will obtain the message from the message cache and hand it to all applications that implement the &lt;code&gt;CommunicationApplication&lt;/code&gt; interface in the method &lt;code&gt;SimulationUnit.processReceiveV2XMessage()&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ApplicationInteraction&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;While most other messages are specific to the a &lt;code&gt;SimulationUnit&lt;/code&gt;, that then forwards the event to its applications, the &lt;code&gt;ApplicationSpecificMessage&lt;/code&gt; is directly handed to all applications.  Thereby, the &lt;code&gt;SimulationUnit&lt;/code&gt;, whose applications shall receive the message can be specified. If this is not done, all applications of all units will get the message and have the opportunity to handle it.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 </description>
     </item>

     <item>
       <title>Integrated Test and Evaluation Framework (ITEF)</title>
       <link>https://www.eclipse.org/mosaic/docs/visualization/itef/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/visualization/itef/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
 &lt;p&gt;&lt;strong&gt;ITEF&lt;/strong&gt; is part of &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;.&lt;br&gt;
 For further information on licenses, feel free to contact us via &lt;strong&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;mosaic@fokus.fraunhofer.de&lt;/a&gt;&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;The Integrated Test and Evaluation Framework (ITEF) is a webtool for planning and evaluating vehicular communication scenarios. It is suited for field operational tests as well as simulations.&lt;/p&gt;
 &lt;p&gt;ITEF also offers a variety of visualization features, making a comparison of different vehicles or between equipped and unequipped vehicles easy. It is structured into 4 screens, whereas the following 3 screens are intended for the visualization.&lt;/p&gt;
 &lt;p&gt;The Replay screen (see Figure 1) is intended to be used for an initial overview of the test run. The main feature is the display of the vehicle movements on a map, while the player can be used to playback the movement situation. In this manner, the ITEF allows a location and time dependent evaluation of simulation test runs.&lt;/p&gt;


 &lt;figure id=&#34;figure-itef-replay-screen&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/replayrun.png&#34; data-caption=&#34;ITEF Replay Screen&#34;&gt;


   &lt;img src=&#34;../images/replayrun.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     ITEF Replay Screen
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;The Evaluate screen (see Figure 2) allows the detailed investigation of the correlations in a test run. The main feature of this screen is to display the behavior summarized over the whole run. The structure of this screen with is similar to the Replay screen. However, the focus here is on the detailed (statistical) summary of evaluated metrics.&lt;/p&gt;


 &lt;figure id=&#34;figure-itef-evaluate-screen&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/evaluaterun.png&#34; data-caption=&#34;ITEF Evaluate Screen&#34;&gt;


   &lt;img src=&#34;../images/evaluaterun.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     ITEF Evaluate Screen
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Finally, the Statistics screen (see Figure 3) provides statistical evaluations of the test and simulation
 run. Currently, statistics on Vehicle Speed, Travel Time, Travel Distance and severalmore are supported.&lt;/p&gt;


 &lt;figure id=&#34;figure-itef-statistics-screen&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/statistics.png&#34; data-caption=&#34;ITEF Statistics Screen&#34;&gt;


   &lt;img src=&#34;../images/statistics.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     ITEF Statistics Screen
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 </description>
     </item>

     <item>
       <title>Network Simulator OMNeT&#43;&#43;</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/</guid>
       <description>&lt;p&gt;&lt;strong&gt;OMNeT++&lt;/strong&gt; is a simulation platform for discrete-event systems. Even though it is primarily targeted at simulating computer networks and
 distributed systems, it cannot be used without any extensions for wireless communication. For this kind of simulations, external model frameworks have to be included.
 Currently, there are two prominent model frameworks which cover whole model suites for according focus of wireless research.
 These are the Mobility Framework and the &lt;strong&gt;INET&lt;/strong&gt; Framework. As INET provides all models necessary for simulating Vehicle-2-X communication,
 it is selected for the integration to Eclipse MOSAIC.&lt;/p&gt;
 &lt;p&gt;For more information on the &lt;strong&gt;INET&lt;/strong&gt; extension you should look closer on the
 &lt;a href=&#34;https://inet.omnetpp.org&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;website&lt;/a&gt;.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Operating System&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;GNU/Linux&lt;br&gt;(Windows with mingw)&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;License&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;GPL, free to use for academic use&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;&lt;strong&gt;Supported version(s)&lt;/strong&gt;&lt;/td&gt;
 &lt;td&gt;OMNeT++
 5.5 &lt;br&gt;INET
 4.1&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;http://www.omnetpp.org&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;http://www.omnetpp.org&lt;/a&gt; &lt;br&gt;
 &lt;a href=&#34;https://inet.omnetpp.org&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://inet.omnetpp.org&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;There are two installation types of the MOSAIC OMNeT++ Federate:&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Type&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;#installation-for-users&#34;&gt;USER&lt;/a&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This installation type addresses those who only want to use the &lt;strong&gt;OMNeT++&lt;/strong&gt; network simulator for simulations.&lt;br&gt;Network configurations can also be adjusted.&lt;br&gt;&lt;br&gt;If you install the federate with this installation type, &lt;strong&gt;OMNeT++
 5.5&lt;/strong&gt; and &lt;strong&gt;INET
 4.1&lt;/strong&gt; will automatically be installed inside &lt;code&gt;&amp;lt;mosaic&amp;gt;/bin/fed/omnetpp&lt;/code&gt; during the installation.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;#installation-for-developers&#34;&gt;DEVELOPER&lt;/a&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;The installation for developers addresses those who want to make changes or extend the MOSAIC OMNeT++ Federate.&lt;br&gt;&lt;br&gt;This installation type awaits that &lt;strong&gt;OMNeT++
 5.5&lt;/strong&gt; and &lt;strong&gt;INET
 4.1&lt;/strong&gt; are already installed on your system and&lt;br&gt;- &lt;code&gt;PATH&lt;/code&gt; contains &lt;code&gt;/path/to/omnetpp/bin&lt;/code&gt;&lt;br&gt;- &lt;code&gt;LD_LIBRARY_PATH&lt;/code&gt; contains &lt;code&gt;/path/to/omnetpp/lib&lt;/code&gt; and &lt;code&gt;/path/to/inet/src&lt;/code&gt;&lt;br&gt;- &lt;code&gt;C_INCLUDE_PATH&lt;/code&gt; contains &lt;code&gt;/path/to/omnetpp/include&lt;/code&gt; and &lt;code&gt;/path/to/inet/src&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;If you already have &lt;strong&gt;OMNeT++
 5.5&lt;/strong&gt; and &lt;strong&gt;INET
 4.1&lt;/strong&gt; installed on your system, but you simply want to use &lt;strong&gt;OMNeT++&lt;/strong&gt; for simulations with Eclipse MOSAIC without developing further the MOSAIC OMNeT++ Federate, you may also choose the &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/#installation-for-developers&#34;&gt;installation for developers&lt;/a&gt; to avoid multiple installations of &lt;strong&gt;OMNeT++&lt;/strong&gt; and &lt;strong&gt;INET&lt;/strong&gt; on your system.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;First of all, please make sure that you have the following libraries installed:
 &lt;code&gt;unzip&lt;/code&gt;, &lt;code&gt;tar&lt;/code&gt;, &lt;code&gt;bison&lt;/code&gt;, &lt;code&gt;flex&lt;/code&gt;, &lt;code&gt;gcc&lt;/code&gt;, &lt;code&gt;python&lt;/code&gt;, &lt;code&gt;protoc&lt;/code&gt;&lt;/p&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;The installation of the current version of the OMNeT++ Federate was tested with protobuf version
 3.7.0.&lt;br&gt;
 It is recommended to install this version. Here you receive more information about &lt;a href=&#34;https://github.com/protocolbuffers/protobuf/blob/master/src/README.md&#34;&gt;how to install protobuf&lt;/a&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;Follow the links and download the source code of OMNeT++, INET and the MOSAIC OMNeT++ Federate:&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Software&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Version&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Link&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;OMNeT++&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 5.5&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;https://omnetpp.org/download/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://omnetpp.org/download/&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;INET&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 4.1&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;https://github.com/inet-framework/inet/releases&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://github.com/inet-framework/inet/releases&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;MOSAIC OMNeT++ Federate&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 20.0&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 &lt;a href=&#34;https://github.com/mosaic-addons/omnetpp-federate/releases&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://github.com/mosaic-addons/omnetpp-federate/releases&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;p&gt;Available parameters of &lt;code&gt;omnet_installer.sh&lt;/code&gt;:&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Parameter&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Value&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-t&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--installation-type&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;&amp;lt;INSTALLATION_TYPE&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Either &lt;code&gt;USER&lt;/code&gt; or &lt;code&gt;DEVELOPER&lt;/code&gt;.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-o&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--omnetpp&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;&amp;lt;PATH_TO_OMNET_TGZ&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provide the archive containing the OMNeT++ source. You can obtain it from
 &lt;a href=&#34;https://omnetpp.org/download/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://omnetpp.org/download/&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-i&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--inet&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;&amp;lt;PATH_TO_INET_TGZ&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provide the archive containing the inet source code. You can obtain it from
 &lt;a href=&#34;https://inet.omnetpp.org/Download.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://inet.omnetpp.org/Download.html&lt;/a&gt;. If not given, the inet-source files are downloaded by this installation script.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-f&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--federate&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;&amp;lt;PATH_TO_FEDERATE_ZIP&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Provide the archive containing the OMNeT++-federate and patches for coupling OMNeT++ to Eclipse MOSAIC. If not given, the omnetpp-federate is downloaded by this installation script.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-so&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--skip-omnetpp&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;-&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Skip the installation of OMNeT++&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-si&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--skip-inet&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;-&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Skip the installation of INET&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-q&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--quiet&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;-&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Less output and no interaction required&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-j&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--parallel&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;&amp;lt;NUMBER_OF_THREADS&amp;gt;&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Enables make to use the given number of compilation threads.&lt;br&gt;Per default your systems maximum is selected automatically.&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-u&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--uninstall&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;-&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Uninstalls the OMNeT++ federate&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;code&gt;-h&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;--help&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;-&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Shows this usage screen&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h4 id=&#34;installation-for-users&#34;&gt;Installation for Users&lt;/h4&gt;
 &lt;p&gt;Run the installation script (this takes a few minutes):&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;cd &amp;lt;mosaic&amp;gt;/bin/fed/omnetpp
 chmod +x omnet_installer.sh`
 ./omnet_install.sh \
     --installation-type USER \
     --omnetpp /path/to/omnetpp-
 5.5-src.tgz \
     --inet /path/to/inet-
 4.1-src.tgz \
     --federate /path/to/omnetpp-federate-
 20.0.zip
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;For the installation type &lt;code&gt;USER&lt;/code&gt; the parameters &lt;code&gt;-o&lt;/code&gt;, &lt;code&gt;-i&lt;/code&gt; and &lt;code&gt;-f&lt;/code&gt; are required.&lt;br&gt;
 The installation script should terminate with &lt;code&gt;SUCESS: The MOSAIC OMNeT++ Federate was successfully installed.&lt;/code&gt; otherwise the installation failed.&lt;/p&gt;
 &lt;h4 id=&#34;installation-for-developers&#34;&gt;Installation for Developers&lt;/h4&gt;
 &lt;p&gt;Run the installation script (this takes a few minutes):&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;cd &amp;lt;mosaic&amp;gt;/bin/fed/omnetpp
 chmod +x omnet_installer.sh`
 ./omnet_install.sh \
     --installation-type DEVELOPER \
     --federate /path/to/omnetpp-federate-
 20.0.zip
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;For the installation type &lt;code&gt;DEVELOPER&lt;/code&gt; the parameter &lt;code&gt;-f&lt;/code&gt; is required.&lt;br&gt;
 The installation script should terminate with &lt;code&gt;SUCCESS: The MOSAIC OMNeT++ Federate was successfully installed.&lt;/code&gt; otherwise the installation failed.&lt;/p&gt;
 &lt;p&gt;
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/extending_mosaic/omnetpp_details/&#34;&gt;Extending MOSAIC OMNeT++ Federate&lt;/a&gt;&lt;/p&gt;
 &lt;h3 id=&#34;omnet-federate-configuration&#34;&gt;OMNeT++ Federate Configuration&lt;/h3&gt;
 &lt;p&gt;To use OMNeT++ as network simulator in an Eclipse MOSAIC simulation, open &lt;code&gt;&amp;lt;scenarioName&amp;gt;/scenario_config.json&lt;/code&gt; and enable OMNeT++:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: {
    ...
    &amp;quot;omnetpp&amp;quot;: true,
    ...
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Now, when you run this scenario, Eclipse MOSAIC will automatically start the MOSAIC OMNeT++ Federate.&lt;/p&gt;
 &lt;p&gt;The main configuration of the MOSAIC OMNeT++ Federate is done within the configuration files &lt;code&gt;omnetpp.ini&lt;/code&gt; and &lt;code&gt;omnetpp_config.json&lt;/code&gt; in the scenario:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ omnetpp
       ├─ omnetpp.ini ...................... OMNeT++ federate configuration file
       └─ omnetpp_config.json .............. Ambassador configuration file
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The whole OMNeT++ specific configuration is done via the &lt;code&gt;omnetpp.ini&lt;/code&gt; file. It covers static parts for the
 simulator coupling such as the specific Eclipse MOSAIC Event Scheduler and the ScenarioManager. Furthermore,
 logging configurations and the typical parameters for the communication layers (MAC, PHY and Radio
 Channel) are addressed. The communication parameters are different for vehicles and RSUs. Please refer
 to the OMNeT++ documentation on the OMNeT++ homepage for further information about the structure
 of the &lt;code&gt;omnetpp.ini&lt;/code&gt; file.&lt;/p&gt;
 &lt;h3 id=&#34;installation-in-docker-environment&#34;&gt;Installation in Docker environment&lt;/h3&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;This is an experimental feature. Please refer to our mailing list if you experience any problems.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;This guide gives instructions to execute the OMNeT++ federate inside a docker container. If you already installed
 OMNeT++ on your machine following the steps before, you can skip this section.&lt;/p&gt;
 &lt;p&gt;Docker is a new approach to execute software. More precisely, it &amp;ldquo;wraps software in a complete filesystem
 that contains everything it needs to run: code, runtime, system tools, and system libraries&amp;rdquo;. As a result, the
 software is executed within a container and its execution does not rely on the environment the container is running in.&lt;/p&gt;
 &lt;p&gt;In context of Eclipse MOSAIC, this approach allows to execute OMNeT++ within a docker container. The user does not
 need to manually install OMNeT++ and can even run OMNeT++ on Windows hosts.&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Install Docker ≥
 1.13 on your machine.&lt;/li&gt;
 &lt;li&gt;To get everything to work, please make sure to execute the following steps depending on your operating system:
 &lt;ul&gt;
 &lt;li&gt;Windows - In the settings, share the drive where Eclipse MOSAIC is installed on. You may need to restart docker in the reset tab.&lt;/li&gt;
 &lt;li&gt;Linux - Make sure your user account belongs to the unix-group &lt;code&gt;docker&lt;/code&gt;. You may need to restart your machine.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;li&gt;Switch to the location of the Dockerfile in &lt;code&gt;&amp;lt;mosaic&amp;gt;/bin/fed/omnetpp&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Execute the following command on command line:&lt;br&gt;
 &lt;code&gt;docker build -t omnetpp-federate&lt;/code&gt;.&lt;br&gt;
 This could take a while to finish.&lt;/li&gt;
 &lt;li&gt;Enter the name of the docker image &lt;code&gt;etc/runtime.json&lt;/code&gt; in the &lt;code&gt;omnetpp&lt;/code&gt;-section into the property &lt;code&gt;dockerImage&lt;/code&gt;:&lt;/li&gt;
 &lt;/ol&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: [
    ...
    {
       &amp;quot;id&amp;quot;: &amp;quot;omnetpp&amp;quot;,
       &amp;quot;dockerImage&amp;quot;: &amp;quot;omnetpp-federate&amp;quot;,
       ...
    },
    ...
 ]
 &lt;/code&gt;&lt;/pre&gt;
 </description>
     </item>

     <item>
       <title>Network Simulator ns-3</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/</guid>
       <description>&lt;p&gt;The ns-3 is a discrete-event network simulator that was developed as a replacement for the popular
 network simulator 2 (ns-2) and mainly focuses upon improving the core architecture, software integration,
 models, and educational components for real-world network devices and protocols. It simulates both
 unicast and multicast protocols and is used extensively in research on mobile ad-hoc networks.&lt;/p&gt;
 &lt;p&gt;Regardless, ns-2 still remains in active use and will continue to be maintained in the near future. For
 Eclipse MOSAIC coupling, only ns-3 will be available.&lt;/p&gt;
 &lt;p&gt;Like other network simulators, ns-3 has a relatively steep learning curve, especially compared to GUI-
 based simulators. If you have no prior experience with ns-3, we recommend familiarizing yourself with
 the ns-3 simulation environment and the ns-3 simulation basics first. The ns-3 documentation can be
 found under: &lt;a href=&#34;https://www.nsnam.org/documentation&#34; target=&#34;_blank&#34;&gt;https://www.nsnam.org/documentation&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;To take your first steps with ns-3, you might want to download 2 the latest version, build a copy of ns-3 (it
 uses the Python-based build-system waf) and take a look at the examples, that are shipped within most
 of the ns-3 source code repositories and packages. You might also examine the simulation output and try
 to adjust it.&lt;/p&gt;
 &lt;p&gt;Typically, a ns-3 user will work under a Linux environment. For those running under Windows, there do
 exist environments which simulate the Linux environment to various degrees. The ns-3 project has in the
 past (but not presently) supported the Cygwin environment for these users (see &lt;a href=&#34;http://www.cygwin.com&#34; target=&#34;_blank&#34;&gt;http://www.cygwin.com&lt;/a&gt;
 for details on downloading). MiniGW is presently not officially supported, however there are also
 some people who managed to use it with ns-3. For detailed information of how to set up ns-3, please refer
 to their Wiki: &lt;a href=&#34;https://www.nsnam.org/wiki/Installation&#34; target=&#34;_blank&#34;&gt;https://www.nsnam.org/wiki/Installation&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;For more information on how to set up ns-3 with Eclipse MOSAIC, please just refer to the following section. We
 prepared an installation script, which manages most of the required work.&lt;/p&gt;
 &lt;div class=&#34;alert alert-warning&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;As stated above, ns-3 is primarily developed on and for GNU/Linux platforms.
 Since Windows is such a widely used platform and Cygwin is not a perfect emulation
 of any Linux, we highly recommended for non-Linux users to consider the installation of a
 Linux virtual machine with a virtual machine environment, such as
 &lt;a href=&#34;https://www.vmware.com/products/workstation-player.html&#34; target=&#34;_blank&#34;&gt;VMware&lt;/a&gt; or &lt;a href=&#34;https://www.virtualbox.org/&#34; target=&#34;_blank&#34;&gt;VirtualBox&lt;/a&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Software information&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Developer(s)&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous, Gustavo Carneiro, Tommaso Pecorella and others&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Written in&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;C++ (core) and Python (bindings)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Operating system&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;GNU/Linux FreeBSD Mac OS X&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;License&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Free software: GNU GPLv2&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Website&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;a href=&#34;http://www.nsnam.org/&#34; target=&#34;_blank&#34;&gt;http://www.nsnam.org/&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Supported version(s)&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;
 3.28&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Dependencies&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;libprotobuf
 3.3.0&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;libxml2&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;libsqlite3&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;strong&gt;Deployed in MOSAIC all-in-one&lt;/strong&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;no (and need a patch to link)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;ns3-ambassador-folder-structure&#34;&gt;ns3-ambassador folder structure&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ ns3
       ├─ ns3_config.json ................. Ambassador configuration file
       ├─ configTechnologies.xml ...........ns-3 federate configuration file
       └─ confWifi.xml .....................ns-3 federate configuration file
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;Eclipse MOSAIC offers support for the current stable release of ns-3 (
 3.28), that was released in March 2018. Older
 versions of ns-3 (prior to
 3.28) are not supported. However, also for newer versions we cannot guarantee
 the correct operation. The coupling to Eclipse MOSAIC is designed in a manner of minimal code changes on the
 ns-3 simulator itself to keep the update capabilities for future versions.&lt;/p&gt;
 &lt;h4 id=&#34;prerequisites&#34;&gt;Prerequisites&lt;/h4&gt;
 &lt;p&gt;For GNU/Linux platforms, the minimal requirements to run basic simulations are a &lt;strong&gt;gcc&lt;/strong&gt; or &lt;strong&gt;clang&lt;/strong&gt; compiler
 and a &lt;strong&gt;Python&lt;/strong&gt; interpreter. At least you need the following packages to be installed:&lt;/p&gt;
 &lt;p&gt;&lt;em&gt;&lt;strong&gt;Minimum requirement:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt;gcc
 g++
 python
 python-dev
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;For a complete list of required packages for different distributions, please refer to the ns-3 installation
 guide: &lt;a href=&#34;https://www.nsnam.org/wiki/Installation&#34; target=&#34;_blank&#34;&gt;https://www.nsnam.org/wiki/Installation&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;Please make sure the following libraries are installed before running the installation script:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;libxml2&lt;/li&gt;
 &lt;li&gt;libsqlite3&lt;/li&gt;
 &lt;li&gt;libprotobuf
 3.3.0&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;run-the-installation-script&#34;&gt;Run the installation script&lt;/h4&gt;
 &lt;div class=&#34;alert alert-warning&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;ns-3 requires several packages to be installed on your computer. You will
 need to ensure, that all required libraries are present on your system before proceeding. You
 may need superuser permissions to install packages.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;div class=&#34;alert alert-warning&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;If your local protobuf version does not fit the required one, the installation
 may fail with an error. In that case, you can run the install script with the &lt;code&gt;-p&lt;/code&gt; flag. This will
 rebuild the protobuf files during installation and allow it to proceed correctly.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;To ease the installation of ns-3 for Eclipse MOSAIC, the installation process has been delegated to an installation
 script, that can be found in the associated ns-3 federate folder.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;ns3-ambassador federate folder structure:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ mosaic/bin/fed/ns3
    └─ ns3
       ├─ Dockerfile.sh ....................Dockerfile for ns-3 federate
       └─ ns3_installer.sh ................ Installation script for ns-3
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;The ns-3 installation script accomplishes the following tasks:&lt;/strong&gt;&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Download ns-3 tarball from the official sources&lt;/li&gt;
 &lt;li&gt;Download the ns-3 federate for Eclipse MOSAIC.&lt;/li&gt;
 &lt;li&gt;Apply a patch to ns-3 in order to make it work with Eclipse MOSAIC.&lt;/li&gt;
 &lt;li&gt;Add the ns-3 federate to the waf build system.&lt;/li&gt;
 &lt;li&gt;Configure and build the patched ns-3 with the ns-3 federate.&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;&lt;strong&gt;In order to start the simulation, the following steps need to be performed:&lt;/strong&gt;&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Set up the &lt;code&gt;confWifi.xml&lt;/code&gt;-file in the scenario folder (see section
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/#configuration&#34;&gt;Configuration&lt;/a&gt;). An example confWifi.xml - file is shipped with the Tiergarten scenario.&lt;/li&gt;
 &lt;li&gt;For reasonable result logging, the logger-configuration in &lt;code&gt;mosaic/etc/logback.xml&lt;/code&gt; has to be adapted to support the ns-3 ambassador and federate.&lt;/li&gt;
 &lt;li&gt;At last ns-3 has to be activated in the &lt;code&gt;mosaic_config.xml&lt;/code&gt; and the simulation can be started.&lt;/li&gt;
 &lt;/ol&gt;
 &lt;h3 id=&#34;installation-in-docker-environment&#34;&gt;Installation in Docker environment&lt;/h3&gt;
 &lt;div class=&#34;alert alert-note&#34;&gt;
   &lt;div&gt;
 &lt;p&gt;This is an experimental feature. Please refer to our mailing list if you experience any problems.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;This guide gives instructions to execute the ns-3 federate inside a docker container. If you already installed
 ns-3 on your machine following the steps before, you can skip this section.&lt;/p&gt;
 &lt;p&gt;Docker is a new approach to execute software. More precisely, it &amp;ldquo;wraps software in a complete filesystem
 that contains everything it needs to run: code, runtime, system tools, and system libraries&amp;rdquo;. As a result, the
 software is executed within a container and its execution does not rely on the environment the container is running in.&lt;/p&gt;
 &lt;p&gt;In context of Eclipse MOSAIC, this approach allows to execute ns-3 within a docker container. The user does not
 need to manually install ns-3 and can even run ns-3 on Windows hosts.&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Install Docker ≥
 1.13 on your machine.&lt;/li&gt;
 &lt;li&gt;To get everything to work, please make sure to execute the following steps depending on your operating system:
 &lt;ul&gt;
 &lt;li&gt;Windows - In the settings, share the drive where Eclipse MOSAIC is installed on. You may need to restart docker in the reset tab.&lt;/li&gt;
 &lt;li&gt;Linux - Make sure your user account belongs to the unix-group &lt;code&gt;docker&lt;/code&gt;. You may need to restart your machine.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;li&gt;Switch to the location of the Dockerfile in &lt;code&gt;&amp;lt;mosaic&amp;gt;/bin/fed/ns3&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Execute the following command on command line:&lt;br&gt;
 &lt;code&gt;docker build -t ns3-federate&lt;/code&gt;.&lt;br&gt;
 This could take a while to finish.&lt;/li&gt;
 &lt;li&gt;Enter the name of the docker image &lt;code&gt;etc/runtime.json&lt;/code&gt; in the &lt;code&gt;ns3&lt;/code&gt;-section into the property &lt;code&gt;dockerImage&lt;/code&gt;:&lt;/li&gt;
 &lt;/ol&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: [
    ...
    {
       &amp;quot;id&amp;quot;: &amp;quot;ns3&amp;quot;,
       &amp;quot;dockerImage&amp;quot;: &amp;quot;ns3-federate&amp;quot;,
       ...
    },
    ...
 ]
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;You can test the installation of your docker image with the Tiergarten scenario, by activating ns3 in the &lt;code&gt;scenario_config.json&lt;/code&gt;.&lt;/p&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;The whole ns-3 specific configuration is done via the &lt;code&gt;confWifi.xml&lt;/code&gt; and &lt;code&gt;configTechnologies.xml&lt;/code&gt; files.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;confWifi.xml:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot; standalone=&amp;quot;no&amp;quot;?&amp;gt;
 &amp;lt;wifi&amp;gt;
     &amp;lt;!-- IPv4 address generator --&amp;gt;
     &amp;lt;ipConfiguration&amp;gt;
         &amp;lt;ip address=&amp;quot;192.168.0.0&amp;quot; mask=&amp;quot;255.255.0.0&amp;quot;/&amp;gt;
     &amp;lt;/ipConfiguration&amp;gt;
     &amp;lt;!-- Calculate a propagation delay --&amp;gt;
     &amp;lt;propagationDelayModel&amp;gt;
         &amp;lt;delay model= &amp;quot;ns3::NonePropagationDelayModel&amp;quot;/&amp;gt;
     &amp;lt;/propagationDelayModel&amp;gt;
     &amp;lt;!-- Modelize the propagation loss through a transmission medium --&amp;gt;
     &amp;lt;propagationLossModel&amp;gt;
         &amp;lt;loss model= &amp;quot;ns3::FriisPropagationLossModel&amp;quot;/&amp;gt;
     &amp;lt;/propagationLossModel&amp;gt;
     &amp;lt;wifiConfiguration&amp;gt;
         &amp;lt;!-- Create non QoS-enabled MAC layers --&amp;gt;
         &amp;lt;wifiMac property=&amp;quot;type&amp;quot; value=&amp;quot;ns3::AdhocWifiMac&amp;quot;/&amp;gt;
         &amp;lt;!-- Wifi PHY mode --&amp;gt;
         &amp;lt;wifiManager property=&amp;quot;phyMode&amp;quot; value=&amp;quot;OfdmRate54Mbps&amp;quot;/&amp;gt;
         &amp;lt;!-- Wifi manager --&amp;gt;
         &amp;lt;wifiManager property=&amp;quot;type&amp;quot; value=&amp;quot;ns3::ConstantRateWifiManager&amp;quot;/&amp;gt;
         &amp;lt;!-- The energy of a received signal should be higher than this threshold (dbm) to allow the PHY layer to detect the signal --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;EnergyDetectionThreshold&amp;quot; value=&amp;quot;-81.0&amp;quot;/&amp;gt;
         &amp;lt;!-- The energy of a received signal should be higher than this threshold (dbm) to allow the PHY layer to declare CCA BUSY state --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;CcaMode1Threshold&amp;quot; value=&amp;quot;-99.0&amp;quot;/&amp;gt;
         &amp;lt;!-- Transmission gain (dB) --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;TxGain&amp;quot; value=&amp;quot;0.0&amp;quot;/&amp;gt;
         &amp;lt;!-- Reception gain (dB) --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;RxGain&amp;quot; value=&amp;quot;0.0&amp;quot;/&amp;gt;
         &amp;lt;!--  Number of transmission power levels available between TxPowerStart and TxPowerEnd included --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;TxPowerLevels&amp;quot; value=&amp;quot;1&amp;quot;/&amp;gt;
         &amp;lt;!-- Maximum available transmission level (dbm) --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;TxPowerEnd&amp;quot; value=&amp;quot;17.0&amp;quot;/&amp;gt;
         &amp;lt;!-- Minimum available transmission level (dbm) --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;TxPowerStart&amp;quot; value=&amp;quot;17.0&amp;quot;/&amp;gt;
         &amp;lt;!-- Loss (dB) in the Signal-to-Noise-Ratio due to non-idealities in the receiver --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;RxNoiseFigure&amp;quot; value=&amp;quot;0.0&amp;quot;/&amp;gt;
         &amp;lt;!-- Channel center frequency = Channel starting frequency + 5 MHz * (nch - 1) --&amp;gt;
         &amp;lt;wifiPhy property=&amp;quot;ChannelNumber&amp;quot; value=&amp;quot;1&amp;quot;/&amp;gt;
       &amp;lt;/wifiConfiguration&amp;gt;
 &amp;lt;/wifi&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The IP configuration information includes the network address and network mask. The ns-3 propagation
 module defines two generic interfaces, namely &lt;strong&gt;PropagationLossModel&lt;/strong&gt; and &lt;strong&gt;PropagationDelayModel&lt;/strong&gt;,
 for the modelling of propagation loss respectively propagation delay.&lt;/p&gt;
 &lt;p&gt;In the default &lt;code&gt;confWifi.xml&lt;/code&gt;, the Wi-Fi device uses the ns-3 standard propagation delay model
 &lt;code&gt;ns3::ConstantSpeedPropagationDelayModel&lt;/code&gt; and the ns-3 standard propagation loss model
 &lt;code&gt;ns3::FriisPropagationLossModel&lt;/code&gt;. Radio propagation models in ns-3 can easily be exchanged with
 the ns-3 class registration system (see the ns-3 documentation for details). The Wi-Fi configuration
 includes additional parameters, like sending power and antenna gain.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;configTechnologies.xml:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot; standalone=&amp;quot;no&amp;quot;?&amp;gt;
     &amp;lt;ns3Configuration&amp;gt;
     &amp;lt;installers&amp;gt;
         &amp;lt;installer type=&amp;quot;ns3::WifiVehicleInstaller&amp;quot; name=&amp;quot;WifiVehicle&amp;quot; file=&amp;quot;confWifi.xml&amp;quot; default=&amp;quot;true&amp;quot; /&amp;gt;
         &amp;lt;installer type=&amp;quot;ns3::MobilityModelInstaller&amp;quot; name=&amp;quot;Mobility&amp;quot; default=&amp;quot;true&amp;quot; /&amp;gt;
     &amp;lt;/installers&amp;gt;
 &amp;lt;/ns3Configuration&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The configuration manager of the ns-3 federate defines, which installer should be loaded for the Wi-Fi
 device (refering to the &lt;code&gt;confWifi.xml&lt;/code&gt;) and the mobility model. Usually, you don’t need to take any
 changes and simply use the default configuration file, that ships with the ns-3 federate.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>3D Visualization (PHABMap)</title>
       <link>https://www.eclipse.org/mosaic/docs/visualization/phabmap/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/visualization/phabmap/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
 &lt;p&gt;The 3D visualization &lt;strong&gt;PHABMap&lt;/strong&gt; is part of &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;&lt;/strong&gt;.&lt;br&gt;
 For further information on licenses, feel free to contact us via &lt;strong&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;mosaic@fokus.fraunhofer.de&lt;/a&gt;&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;The Eclipse MOSAIC 3D Visualization Tool is based on the PHABMACS vehicle simulator and uses the same 3D
 engine and models to visualize vehicle movements and various events which occur during the simulation.
 Next to the road network, which can be optionally rendered by the visualizer, the following units and
 events are visualized:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Vehicle movements coming from the traffic simulation&lt;/li&gt;
 &lt;li&gt;Road Side Units at their defined location&lt;/li&gt;
 &lt;li&gt;V2X-messages sent via cellular communication (indicated as green circles)&lt;/li&gt;
 &lt;li&gt;V2X-messages sent via ITS-G5 communication (indicated as blue circles)&lt;/li&gt;
 &lt;li&gt;V2X-messages received by vehicles (indicated as red circles)&lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-the-3d-visualization-tool-phabmap-displaying-events-from-the-simulation&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/phabmap.jpg&#34; data-caption=&#34;The 3D visualization tool PHABMap displaying events from the simulation&#34;&gt;


   &lt;img src=&#34;../images/phabmap.jpg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     The 3D visualization tool PHABMap displaying events from the simulation
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 </description>
     </item>

     <item>
       <title>Sumo Ambassador Implementation</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/sumo_ambassador_details/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/sumo_ambassador_details/</guid>
       <description>&lt;p&gt;The Simulation of Urban Mobility (SUMO) simulator is an open source microscopic, multi-modal traf-
 fic simulation package which is developed by the Institute of Transportation research at the German
 Aerospace Centre. It is designed to handle large road networks faster than real-time. Each vehicle has
 an own route and is simulated individually. To simulate the movements of the vehicles on the network,
 a model is used that uses discrete time steps of e.g. 1 s. Thousands of vehicles can be simulated in real
 time on a desktop PC, including simulation of traffic lights, right-of-way rules, and lane changing models.
 Simulations can either run via the command line or are visualized using the openGL-API (SUMO-GUI).
 SUMO networks are created by importing other formats, such as OpenStreetMap data, Shapefiles or
 TIGE-maps; or by generating artificial networks. Furthermore, vehicle routes, based on different routing
 paradigms, can be computed.&lt;/p&gt;
 &lt;h3 id=&#34;sumo-and-eclipse-mosaic&#34;&gt;SUMO and Eclipse MOSAIC&lt;/h3&gt;
 &lt;p&gt;We have integrated the traffic simulator SUMO to be able to simulate heterogeneous driving vehicles and a set of vehicles that have a predefined routes based on an imported roadmap. Additionally, during
 the runtime of a simulation, it is possible that routes of simulated vehicles are changed and that vehicle positions are extracted at arbitrary points in time. The integration of SUMO into a Eclipse MOSAIC based simulation is illustrated in the following figure. The integrated Traffic Control Interface (TraCI) Server offers an interface to exchange commands and positions using a socket interface with a proprietary byte protocol. Analogous to the TraCI Server, a TraCI Client is implemented that is integrated in an ambassador implementing the TraCI protocol. Therefore, SUMO can be integrated without modifications.&lt;/p&gt;


 &lt;figure id=&#34;figure-sumo-connected-to-eclipse-mosaic&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/sumo-connected-to-mosaic.jpeg&#34; data-caption=&#34;SUMO connected to Eclipse MOSAIC&#34;&gt;


   &lt;img src=&#34;../images/sumo-connected-to-mosaic.jpeg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     SUMO connected to Eclipse MOSAIC
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;During a simulation run, per default SUMO is paused and TraCI is listening for commands. After each
 advanced time grant, SUMO offers the new vehicle positions which are broadcast by its ambassador
 to other federates. Furthermore, if the ambassador receives a request to change the route of a specific
 vehicle, it is forwarded to SUMO. Thus, at the next time-advancement, the new route is integrated.&lt;/p&gt;
 &lt;h3 id=&#34;simulation-of-vehicles&#34;&gt;Simulation of Vehicles&lt;/h3&gt;
 &lt;p&gt;For each vehicle which has been defined in the mapping configuration, a &lt;code&gt;VehicleRegistration&lt;/code&gt; interaction is sent
 to the &lt;code&gt;SumoAmbassador&lt;/code&gt; which adds those vehicles to the simulation via TraCI. Furthermore, vehicle
 data is subscribed which is updated with every simulation step. After each step of the simulation this
 data is bundled into a &lt;code&gt;VehicleInfo&lt;/code&gt; object which is distributed among other ambassadors within the
 &lt;code&gt;VehicleUpdates&lt;/code&gt; interaction. The following data is available for each vehicle:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Position&lt;/li&gt;
 &lt;li&gt;Speed, Acceleration, Heading, Slope&lt;/li&gt;
 &lt;li&gt;State of vehicle signals (e.g. turn indicators)&lt;/li&gt;
 &lt;li&gt;Emission dispersion (CO2, NOX, etc.)&lt;/li&gt;
 &lt;li&gt;Fuel consumption&lt;/li&gt;
 &lt;li&gt;Information about the road the vehicle is driving on (road position)&lt;/li&gt;
 &lt;li&gt;Id of the route&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h3 id=&#34;traffic-lights-in-sumo&#34;&gt;Traffic lights in SUMO&lt;/h3&gt;
 &lt;p&gt;Depending on which light is active (red, yellow or green), every traffic light got different phases. In theory,
 any combination of dis- or enabled lights is possible, but SUMO only handles combinations which make
 sense. In SUMOs traffic light concept every traffic light got a bitset of the status of each phase. Every
 bitset is a combination as mentioned above. When a car approaches a junction, it gets the actual bitset
 (combination) of the traffic light. To explain the code, an example is given:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;tl-logic type=&amp;quot;static&amp;quot;&amp;gt;
     &amp;lt;key&amp;gt;0&amp;lt;/key&amp;gt;
     &amp;lt;subkey&amp;gt;my program&amp;lt;/subkey&amp;gt;
     &amp;lt;phaseno&amp;gt;8&amp;lt;/phaseno&amp;gt;
     &amp;lt;offset&amp;gt;0&amp;lt;/offset&amp;gt;
     &amp;lt;phase duration=&amp;quot;31&amp;quot; state=&amp;quot;GGggrrrrGGggrrrr&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;5&amp;quot; state=&amp;quot;yyggrrrryyggrrrr&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;6&amp;quot; state=&amp;quot;rrGGrrrrrrGGrrrr&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;5&amp;quot; state=&amp;quot;rryyrrrrrryyrrrr&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;31&amp;quot; state=&amp;quot;rrrrGGggrrrrGGgg&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;5&amp;quot; state=&amp;quot;rrrryyggrrrryygg&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;6&amp;quot; state=&amp;quot;rrrrrrGGrrrrrrGG&amp;quot;/&amp;gt;
     &amp;lt;phase duration=&amp;quot;5&amp;quot; state=&amp;quot;rrrrrryyrrrrrryy&amp;quot;/&amp;gt;
 &amp;lt;/tl-logic&amp;gt;
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This example shows the traffic light program of one junction. It shows the different status’ of each light
 of each traffic signal, which are positioned on the junction. In this example every string of a phase e.g.
 &amp;ldquo;GGggrrrrGGggrrrr&amp;rdquo; (first phase) got 16 characters. Every char stands for one light on the junction. On
 this junction are four traffic lights with four signals each. To understand the different status of each light
 in one period (8 phases) the program should be read from top to the bottom. It is possible to change or
 create your own program by editing the .net file with the tool Netedit.&lt;/p&gt;
 &lt;h3 id=&#34;handling-of-traffic-lights-in-eclipse-mosaic&#34;&gt;Handling of traffic lights in Eclipse MOSAIC&lt;/h3&gt;
 &lt;p&gt;After the TraCI connection has been established, all available traffic light groups are read out of SUMO via
 TraCI. This information is packed into the three classes &lt;code&gt;TrafficLightGroup&lt;/code&gt;, &lt;code&gt;TrafficLightSignal&lt;/code&gt;,
 and &lt;code&gt;TrafficLightPhase&lt;/code&gt;. While a traffic light group contains a list of signals which control one intersec-
 tion (which can consist of several nodes), a list of all existing traffic light groups is sent to the RTI via a
 &lt;code&gt;ScenarioTrafficLightRegistration&lt;/code&gt; interaction.&lt;/p&gt;
 &lt;h3 id=&#34;traci-client-implementation&#34;&gt;TraCI Client Implementation&lt;/h3&gt;
 &lt;p&gt;The SumoAmbassador communicates with the federate (SUMO process) via TraCI. In this socket based
 communication protocol, the server (SUMO) listens to commands and responds accordingly.&lt;/p&gt;
 &lt;p&gt;Each message send to SUMO consist of a header and the command or result message, according to the
 following scheme:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt; 0                7 8                15
 +--------------------------------------+
 | Message Length including this header |
 +--------------------------------------+
 |      (Message Length, continued)     |
 +--------------------------------------+  \
 |      Length      |    Identifier     |  |
 +--------------------------------------+   &amp;gt; Command / Result_0
 |      Command / Result_0 content      |  |
 +--------------------------------------+  /
 ...
 +--------------------------------------+  \
 |      Length      |    Identifier     |  |
 +--------------------------------------+   &amp;gt; Command / Result_n -1
 |     Command / Result_n-1 content     |  |
 +--------------------------------------+  /
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;A more detailed description can be found here:
 &lt;a href=&#34;http://sumo.dlr.de/wiki/TraCI/Protocol&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;http://sumo.dlr.de/wiki/TraCI/Protocol&lt;/a&gt;&lt;/p&gt;
 &lt;h4 id=&#34;commands&#34;&gt;Commands&lt;/h4&gt;
 &lt;p&gt;Each TraCI command is identified by an command identifier. For example, the command 0xC4 is used to
 change the state of a vehicle. Most of the commands need further specification, such as the parameter of
 the vehicle which is required to be changed. Those parameters are usually accessed by variable identifiers
 (e.g. 0x40 addresses the speed of an entity). A full list of commands and variables supported by TraCI can
 be found here:
 &lt;a href=&#34;http://sumo.dlr.de/wiki/TraCI&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;http://sumo.dlr.de/wiki/TraCI&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;Here is an example of a command message to change the speed of the vehicle &amp;ldquo;veh_0&amp;rdquo; to 14m/s:&lt;/p&gt;
 &lt;pre&gt;&lt;code&gt; 0                 7 8                 15                23 24               31
 +-----------------------------------------------------------------------------+
 |                             25 (Message length)                             |
 +-----------------------------------------------------------------------------+
 |    21 (Length)    |  0xC4 (Command)  |   0x40 (Variable) |
 +-----------------------------------------------------------------------------+
              5 (String length as 4 Byte Integer)           |        &amp;quot;v&amp;quot;       |
 +-----------------------------------------------------------------------------+
 |        &amp;quot;e&amp;quot;        |        &amp;quot;h&amp;quot;       |        &amp;quot;_&amp;quot;        |        &amp;quot;0&amp;quot;       |
 +-----------------------------------------------------------------------------+
 | 0x0B (Double type)|                   40.0 (8 Byte Double)
 +-----------------------------------------------------------------------------+

 +-----------------------------------------------------------------------------+
                     |
 +-------------------+
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h4 id=&#34;abstracttracicommand&#34;&gt;AbstractTraciCommand&lt;/h4&gt;
 &lt;p&gt;In the TraCI client implementation of the &lt;code&gt;SumoAmbassador&lt;/code&gt; the whole construction of messages is done in
 the class &lt;code&gt;AbstractTraciCommand&lt;/code&gt;. The message header containing the message and command lengths
 is constructed automatically as well as all parameters defined by the specific command. To achieve this,
 each class which extends the &lt;code&gt;AbstractTraciCommand&lt;/code&gt; needs to define the command, the variable and
 all parameters which are required for the specific command:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;protected VehicleSetSpeed() {
     super(TraciVersion.LOWEST);

     write()
         .command(0xC4)                // = change vehicle state
         .variable(0x04)               // = set speed of entity
         .writeStringParam()           // = vehicle id
         .writeDoubleParamWithType();  // = speed value
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This example shows the command implementation for setting the speed for a vehicle. In the constructor,
 the write methods provides a builder-like construct allowing to define the command, the variable, and all
 parameters which are later passed dynamically to the command. Here, the command is specified as &lt;code&gt;0xC4&lt;/code&gt; (= change vehicle state) and the variable as &lt;code&gt;0x04&lt;/code&gt; (= speed of the entity). Furthermore, two parameters are
 defined: The first string parameter represents the ID of the vehicle, the second double parameter defines
 the speed value to be set (according to
 &lt;a href=&#34;http://sumo.dlr.de/wiki/TraCI/Change_Vehicle_State&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;http://sumo.dlr.de/wiki/TraCI/Change_Vehicle_State&lt;/a&gt;).
 Note, the order of the specified command contents is from crucial importance. E.g. the &lt;code&gt;command&lt;/code&gt; must
 always be specified before the &lt;code&gt;variable&lt;/code&gt;, and the variable before all parameters.&lt;/p&gt;
 &lt;p&gt;All parameters defined in the constructor (here: &lt;code&gt;[String, Double]&lt;/code&gt; ), need to be assigned with values
 as soon as the command is executed. For this purpose, the command implementation needs to call the
 method execute of the super class with the parameter values in the specified order:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;public void setSpeed(TraciConnection traciCon, String vehicleId, double speedValue) {
     super.execute(traciCon, vehicleId, value);
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Within the execute method, the &lt;code&gt;AbstractTraciCommand&lt;/code&gt; constructs the whole message and sends it to
 the TraCI server (SUMO). Furthermore, the &lt;code&gt;AbstractTraciCommand&lt;/code&gt; also reads the response, extracts the
 status of the response (successful or error) and reads all values returned by the server. Usually, commands
 which changes the state of an entity only (like &lt;code&gt;VehicleSetSpeed&lt;/code&gt;) do not respond with complex results.
 However, a command which wants to retrieve a value of an entity needs to read out the result from the
 response (e.g. &lt;code&gt;VehicleGetRouteId&lt;/code&gt; which returns the current route identifier of the vehicle). For this
 purpose, each command needs to specify how the response should be handled:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;protected VehicleGetRouteId() {
     super(TraciVersion.LOWEST);

     write()
         .command(0xA4)      // = retrieve vehicle state
         .variable(0x53)     // = route id of entity
         .writeStringParam(); // = write vehicle id

     read()
         .skipBytes(2)          // = skip command and variable in response
         .skipString()          // = skip vehicle id, not relevant
         .readStringWithType(); // = read route id
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This example shows the command implementation for getting the route id of a vehicle. As well as &lt;code&gt;write&lt;/code&gt;,
 the method read returns a builder-like construct which provides methods to define how the response is
 handled. Here, the first two bytes of the response should be skipped, as well as the string which follows
 afterwards. The value the command is interested in is the following string value which holds the id of
 the route. By using the method &lt;code&gt;readStringWithType&lt;/code&gt; the string is read out and is passed to the method
 &lt;code&gt;constructResult&lt;/code&gt; which needs to be implemented by the command as well:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;public String getRouteId(TraciConnection con, String vehicle) {
     return super.executeAndReturn(con, vehicle);
 }

 @Override
 protected String constructResult(Status status, Object... objects) {
     return (String) objects[0];
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;In this simple case the result of the command consists of one result object only (the route id). Therefore,
 it is just extracted from the array of result objects and directly returned.&lt;/p&gt;
 &lt;h4 id=&#34;writing-parameters&#34;&gt;Writing parameters&lt;/h4&gt;
 &lt;p&gt;In order to write parameters and read results according to the specification of the protocol, several reader
 and writer implementations exist. For parameters to be written in the command various writers exists
 to write single bytes, strings, integers, and doubles, or special writers for writing lists. The same is for
 readers.&lt;/p&gt;
 &lt;p&gt;In the following example, the IntegerTraciWriter is shown:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;public class IntegerTraciWriter extends AbstractTraciParameterWriter&amp;lt;Integer&amp;gt; {

     public IntegerTraciWriter() {
         super(4);
     }

     public IntegerTraciWriter(int value) {
         super(4, value);
     }

     @Override
     public int getVariableLength(Integer argument) {
         return getLength();
     }

     @Override
     public void write(DataOutputStream out) throws IOException {
         out.writeInt(value);
     }

     @Override
     public void writeVariableArgument(DataOutputStream out, Integer argument) {
         out.writeInt(argument);
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Each writer has two tasks. Firstly, it needs to determine the length of the parameter value. For example,
 an integer parameter is always 4 bytes long, whereas the length of a string parameter depends on the
 size of the argument. Therefore, each writer needs to be able to determine the variable length according
 to a given value. Secondly, it needs to write out the actual value into the &lt;code&gt;DataOutputStream&lt;/code&gt; (which
 represents the channel to the TraCI server). Furthermore is each writer able to write fixed values, such as
 the command identifier which does not change, or variable arguments, such as the vehicle id.&lt;/p&gt;
 &lt;h4 id=&#34;reading-results&#34;&gt;Reading results&lt;/h4&gt;
 &lt;p&gt;In the following example, the IntegerTraciReader is shown:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;public class IntegerTraciReader extends AbstractTraciResultReader&amp;lt;Integer&amp;gt; {

     public IntegerTraciReader() {
         super(null);
     }

     public IntegerTraciReader(Matcher&amp;lt;Integer&amp;gt; matcher) {
         super(matcher);
     }

     @Override
     protected Integer readFromStream(DataInputStream in) throws IOException {
         return readInt(in);
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;A reader has three tasks. Firstly, it reads out a value from the &lt;code&gt;DataInputStream&lt;/code&gt; (which represents the
 response channel to the TraCI client) according to the protocol specification. For example, an integer
 can be read out directly, while a string requires several single reading operations. Secondly, the reader
 needs to take track of the number of bytes it has read in total. To achieve this it is recommended to use
 the provided methods of the super class, such as &lt;code&gt;readInt&lt;/code&gt;, &lt;code&gt;readString&lt;/code&gt;, or &lt;code&gt;readByte&lt;/code&gt; .However, if values
 need to be read directly from the DataInputStream, the protected field &lt;code&gt;numBytesRead&lt;/code&gt; must always be
 increased accordingly. Thirdly, the reader needs to define if the read out value fulfils certain requirements.
 Such requirement can be, that a certain value is expected. In this case, a matcher might be passed to the
 super constructor.&lt;/p&gt;
 &lt;h4 id=&#34;accessing-the-commands&#34;&gt;Accessing the commands&lt;/h4&gt;
 &lt;p&gt;For each command, only one object should be instantiated during runtime. To achieve this, the
 &lt;code&gt;CommandRegister&lt;/code&gt; is used. This class stores a command once it is created returns only one instance per
 command class:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;final RouteAdd routeAddCommand = commandRegister.getOrCreate(RouteAdd.class);
 //... do something
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;However, commands should not be accessed directly in the code, but rather using the various facades
 available:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;TraciRouteFacade&lt;/code&gt; - Route specific command calls, such as addRoute and getRouteEdges .&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;TraciSimulationFacade&lt;/code&gt; - Provides methods to control the simulation, such as simulateStep .&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;TraciTrafficLightFacade&lt;/code&gt; - Provides methods to get or set values for traffic lights.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;TraciVehicleFacade&lt;/code&gt; - Provides methods to get or set values for vehicles.
 All those facades can be accessed via the &lt;code&gt;TraciClient&lt;/code&gt;.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;exception-handling&#34;&gt;Exception handling&lt;/h4&gt;
 &lt;p&gt;Exceptions are thrown and handled as following:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;
 &lt;p&gt;If a command results in a status response with the status code Error, a &lt;code&gt;TraciCommandException&lt;/code&gt;
 is thrown. If this exception is thrown, the TraCI connection is still alive and can be used for
 further commands. The facades decide how to handle this exception then and may throw an
 &lt;code&gt;InternalFederateException&lt;/code&gt; or log a warning message.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;If a command could not be written properly, or the result could not be read out as wished, an
 &lt;code&gt;InternalFederateException&lt;/code&gt; is thrown and an &lt;code&gt;Emergency Exit&lt;/code&gt; is initiated, which eventually
 shuts down the TraCI connection. This also happens if a reader or writer throws any kind of
 Exception.&lt;/p&gt;
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4 id=&#34;version-handling&#34;&gt;Version handling&lt;/h4&gt;
 &lt;p&gt;With future releases of SUMO new TraCI commands will emerge. To achieve downward compatibility
 each command can define the lowest TraCI Version it supports. For example, a command which was
 introduced with SUMO 0.30.0 and is annotated accordingly, would be skipped automatically if the version
 of the TraCI server is lower. However, this concept has not been tested yet properly.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Simple Network Simulator (SNS)</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns/</link>
       <pubDate>Tue, 30 Jun 2020 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns/</guid>
       <description>&lt;p&gt;The Simple Network Simulator (SNS) aims to provide simple and fast capabilities for the
 transmission of V2X-messages using Ad hoc communication. In order to stay performant the simulator makes abstractions
 in certain places. Those abstractions will be discussed later on.&lt;/p&gt;
 &lt;h2 id=&#34;configuration&#34;&gt;Configuration&lt;/h2&gt;
 &lt;p&gt;The SNS offers some configurability regarding the way transmissions are simulated.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Main Configuration:&lt;/strong&gt;&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Parameter&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;type&lt;/th&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Default Value&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;maximumTtl&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Defines the upper bound for the amount of hops a message can make. (Note: messages can have individual &lt;code&gt;ttl&lt;/code&gt;&amp;rsquo;s)&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;int&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;10&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;singlehopRadius&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Fallback radius to be used for transmission, if no radius is defined in the &lt;code&gt;AdhocConfiguration&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;double&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;509.4&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;singlehopDelay&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;A delay configuration for the direct communication between two nodes. (
 &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/extending_mosaic/delay_models/&#34;&gt;See here&lt;/a&gt;)&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Delay&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;`ConstantDelay       |&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;singlehopTransmission&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;This contains the transmission configurations for &lt;code&gt;lossProbability&lt;/code&gt; and &lt;code&gt;maxRetries&lt;/code&gt;.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;CTransmission&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;n/a&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;adhocTransmissionModel&lt;/code&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;A class extending &lt;code&gt;AdhocTransmissionModel&lt;/code&gt;, this will decide the logic for transmissions.&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;AdhocTransmissionModel&lt;/td&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;SimpleAdhoc TransmissionModel&lt;/code&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;blockquote&gt;
 &lt;p&gt;On default the SNS will use the &lt;code&gt;SimpleAdhocTransmissionModel&lt;/code&gt; with a &lt;code&gt;ConstantDelay&lt;/code&gt; using 0 as delay. This means it usually
 makes sense to specify the &lt;code&gt;AdhocTransmissionModel&lt;/code&gt; explicitly and use a more realistic &lt;code&gt;Delay&lt;/code&gt;.
 &lt;strong&gt;Example Configuration:&lt;/strong&gt;&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;maximumTtl&amp;quot;: 20,
     &amp;quot;singlehopRadius&amp;quot;: 300.5,
     &amp;quot;singlehopDelay&amp;quot;: {
         &amp;quot;type&amp;quot;: &amp;quot;SimpleRandomDelay&amp;quot;,
         &amp;quot;steps&amp;quot;: 5,
         &amp;quot;minDelay&amp;quot;: &amp;quot;1.5 ms&amp;quot;,
         &amp;quot;maxDelay&amp;quot;: &amp;quot;2.5 ms&amp;quot;
     },
     &amp;quot;singlehopTransmission&amp;quot;: {
         &amp;quot;lossProbability&amp;quot;: 0.0,
         &amp;quot;maxRetries&amp;quot;: 0
     },
     &amp;quot;adhocTransmissionModel&amp;quot;: {
         &amp;quot;type&amp;quot;: &amp;quot;SimpleAdhocTransmissionModel&amp;quot;,
         &amp;quot;simpleMultihopDelay&amp;quot;: {
             &amp;quot;type&amp;quot;: &amp;quot;GammaRandomDelay&amp;quot;,
             &amp;quot;minDelay&amp;quot;: &amp;quot;10 ms&amp;quot;,
             &amp;quot;expDelay&amp;quot;: &amp;quot;30 ms&amp;quot;
         },
         &amp;quot;simpleMultihopTransmission&amp;quot;: {
             &amp;quot;lossProbability&amp;quot;: 0.1,
             &amp;quot;maxRetries&amp;quot;: 2
         }
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h2 id=&#34;transmission-logic&#34;&gt;Transmission Logic&lt;/h2&gt;
 &lt;p&gt;SNS differentiates between two types of Ad hoc transmissions, geographically- and topologically-scoped transmissions, which
 generally are abbreviated with &lt;em&gt;GeoCast&lt;/em&gt; and &lt;em&gt;TopoCast&lt;/em&gt; respectively.&lt;br&gt;
 GeoCasts are limited to &lt;em&gt;BroadCasts&lt;/em&gt;. Accordingly, there is no explicit addressing
 of receivers (other than 255.255.255.255), instead a destination area is specified. However, GeoCasts allow for multihop forwarding.&lt;br&gt;
 TopoCasts on the other hand use means of IPv4 addressing to transmit messages. Since the SNS was not build to simulate transmissions using complex topology-constructs, TopoCasts
 are limited to transmissions with a single hop. However, TopoCasts support &lt;em&gt;BroadCasts&lt;/em&gt; and &lt;em&gt;UniCasts&lt;/em&gt; (we are omitting Anycasts).
 Most transmissions in the Ad hoc domain will be some form of Broadcast, meaning every reachable entity is eligible to
 receive a message.&lt;/p&gt;


 &lt;div class=&#34;svg-wrap mt-1 mb-4&#34;&gt;
   &lt;div class=&#34;inner&#34;&gt;
     &lt;svg id=&#34;mermaid-1603209753374&#34; width=&#34;100%&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34; xmlns:xlink=&#34;http://www.w3.org/1999/xlink&#34; height=&#34;1207.332763671875&#34; style=&#34;max-width: 817.0913696289062px;&#34; viewBox=&#34;0 0 817.0913696289062 1207.332763671875&#34;&gt;&lt;style&gt;#mermaid-1603209753374{font-family:&#34;trebuchet ms&#34;,verdana,arial;font-size:16px;fill:#333;}#mermaid-1603209753374 .error-icon{fill:#552222;}#mermaid-1603209753374 .error-text{fill:#552222;stroke:#552222;}#mermaid-1603209753374 .edge-thickness-normal{stroke-width:2px;}#mermaid-1603209753374 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-1603209753374 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-1603209753374 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-1603209753374 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-1603209753374 .marker{fill:#333333;}#mermaid-1603209753374 .marker.cross{stroke:#333333;}#mermaid-1603209753374 svg{font-family:&#34;trebuchet ms&#34;,verdana,arial;font-size:16px;}#mermaid-1603209753374 .label{font-family:&#34;trebuchet ms&#34;,verdana,arial;color:#333;}#mermaid-1603209753374 .label text{fill:#333;}#mermaid-1603209753374 .node rect,#mermaid-1603209753374 .node circle,#mermaid-1603209753374 .node ellipse,#mermaid-1603209753374 .node polygon,#mermaid-1603209753374 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-1603209753374 .node .label{text-align:center;}#mermaid-1603209753374 .node.clickable{cursor:pointer;}#mermaid-1603209753374 .arrowheadPath{fill:#333333;}#mermaid-1603209753374 .edgePath .path{stroke:#333333;stroke-width:1.5px;}#mermaid-1603209753374 .flowchart-link{stroke:#333333;fill:none;}#mermaid-1603209753374 .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-1603209753374 .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-1603209753374 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-1603209753374 .cluster text{fill:#333;}#mermaid-1603209753374 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:&#34;trebuchet ms&#34;,verdana,arial;font-size:12px;background:hsl(80,100%,96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-1603209753374:root{--mermaid-font-family:&#34;trebuchet ms&#34;,verdana,arial;}#mermaid-1603209753374 flowchart{fill:apa;}&lt;/style&gt;&lt;g&gt;&lt;g class=&#34;output&#34;&gt;&lt;g class=&#34;clusters&#34;&gt;&lt;/g&gt;&lt;g class=&#34;edgePaths&#34;&gt;&lt;g class=&#34;edgePath LS-id1 LE-id2&#34; id=&#34;L-id1-id2&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M239.4164047241211,47L239.4164047241211,72L239.9164047241211,97.5&#34; marker-end=&#34;url(#arrowhead39)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead39&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id2 LE-id3&#34; id=&#34;L-id2-id3&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M195.9271276785066,224.93259795438553L112.671875,302.921875L113.171875,337.921875&#34; marker-end=&#34;url(#arrowhead40)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead40&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id2 LE-id4&#34; id=&#34;L-id2-id4&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M283.9056817697356,224.93259795438553L366.1609344482422,302.921875L366.66093444824224,347.42812499999997&#34; marker-end=&#34;url(#arrowhead41)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead41&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id3 LE-id5&#34; id=&#34;L-id3-id5&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M113.171875,478.6171875L112.671875,512.6171875L112.671875,616.9343719482422&#34; marker-end=&#34;url(#arrowhead42)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead42&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id4 LE-id6&#34; id=&#34;L-id4-id6&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M366.66093444824224,469.1109344482418L366.1609344482422,512.6171875L366.6609344482422,547.6171905517579&#34; marker-end=&#34;url(#arrowhead43)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead43&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id6 LE-id7&#34; id=&#34;L-id6-id7&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M314.730715999631,693.3213409996309L218.50390625,779.2515563964844L218.50390625,914.0421752929688&#34; marker-end=&#34;url(#arrowhead44)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead44&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id6 LE-id8&#34; id=&#34;L-id6-id8&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M418.59115610436135,693.321343895639L513.8179626464844,779.2515563964844L514.3179626464845,814.2515625&#34; marker-end=&#34;url(#arrowhead45)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead45&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id8 LE-id9&#34; id=&#34;L-id8-id9&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M451.77749555523815,1010.2923332017227L360.3570251464844,1106.8327941894531L360.3570251464844,1150.8327941894531&#34; marker-end=&#34;url(#arrowhead46)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead46&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;g class=&#34;edgePath LS-id8 LE-id10&#34; id=&#34;L-id8-id10&#34; style=&#34;opacity: 1;&#34;&gt;&lt;path class=&#34;path&#34; d=&#34;M576.8584356425159,1010.292339503968L667.2789001464844,1106.8327941894531L667.2789001464844,1141.3327941894531&#34; marker-end=&#34;url(#arrowhead47)&#34; style=&#34;fill:none&#34;&gt;&lt;/path&gt;&lt;defs&gt;&lt;marker id=&#34;arrowhead47&#34; viewBox=&#34;0 0 10 10&#34; refX=&#34;9&#34; refY=&#34;5&#34; markerUnits=&#34;strokeWidth&#34; markerWidth=&#34;8&#34; markerHeight=&#34;6&#34; orient=&#34;auto&#34;&gt;&lt;path d=&#34;M 0 0 L 10 5 L 0 10 z&#34; class=&#34;arrowheadPath&#34; style=&#34;stroke-width: 1; stroke-dasharray: 1, 0;&#34;&gt;&lt;/path&gt;&lt;/marker&gt;&lt;/defs&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabels&#34;&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(0,0)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;0&#34; height=&#34;0&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;0&#34; height=&#34;0&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id1-id2&#34; class=&#34;edgeLabel L-LS-id1&#39; L-LE-id2&#34;&gt;&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(112.671875,302.921875)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-33.0859375,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;66.171875&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;66.171875&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id2-id3&#34; class=&#34;edgeLabel L-LS-id2&#39; L-LE-id3&#34;&gt;TopoCast&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(366.1609344482422,302.921875)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-29.46875,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;58.9375&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;58.9375&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id2-id4&#34; class=&#34;edgeLabel L-LS-id2&#39; L-LE-id4&#34;&gt;GeoCast&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(112.671875,512.6171875)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-12.1640625,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id3-id5&#34; class=&#34;edgeLabel L-LS-id3&#39; L-LE-id5&#34;&gt;Yes&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(366.1609344482422,512.6171875)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-12.1640625,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id4-id6&#34; class=&#34;edgeLabel L-LS-id4&#39; L-LE-id6&#34;&gt;Yes&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(218.50390625,779.2515563964844)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-12.1640625,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id6-id7&#34; class=&#34;edgeLabel L-LS-id6&#39; L-LE-id7&#34;&gt;Yes&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(513.8179626464844,779.2515563964844)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-9.3984375,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;18.796875&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;18.796875&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id6-id8&#34; class=&#34;edgeLabel L-LS-id6&#39; L-LE-id8&#34;&gt;No&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(360.3570251464844,1106.8327941894531)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-12.1640625,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;24.328125&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id8-id9&#34; class=&#34;edgeLabel L-LS-id8&#39; L-LE-id9&#34;&gt;Yes&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;edgeLabel&#34; transform=&#34;translate(667.2789001464844,1106.8327941894531)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;g transform=&#34;translate(-9.3984375,-9.5)&#34; class=&#34;label&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; width=&#34;18.796875&#34; height=&#34;19&#34;&gt;&lt;/rect&gt;&lt;foreignObject width=&#34;18.796875&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;&lt;span id=&#34;L-L-id8-id10&#34; class=&#34;edgeLabel L-LS-id8&#39; L-LE-id10&#34;&gt;No&lt;/span&gt;&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;nodes&#34;&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id1-28&#34; transform=&#34;translate(239.4164047241211,27.5)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;rect rx=&#34;0&#34; ry=&#34;0&#34; x=&#34;-72.1953125&#34; y=&#34;-19.5&#34; width=&#34;144.390625&#34; height=&#34;39&#34; class=&#34;label-container&#34;&gt;&lt;/rect&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-62.1953125,-9.5)&#34;&gt;&lt;foreignObject width=&#34;124.390625&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;V2X-Transmission&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id2-29&#34; transform=&#34;translate(239.4164047241211,182.7109375)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;polygon points=&#34;85.7109375,0 171.421875,-85.7109375 85.7109375,-171.421875 0,-85.7109375&#34; transform=&#34;translate(-85.7109375,85.7109375)&#34; class=&#34;label-container&#34;&gt;&lt;/polygon&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-65.734375,-9.5)&#34;&gt;&lt;foreignObject width=&#34;131.46875&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Transmission Type&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id3-32&#34; transform=&#34;translate(112.671875,407.76953125)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;polygon points=&#34;70.34765625,0 140.6953125,-70.34765625 70.34765625,-140.6953125 0,-70.34765625&#34; transform=&#34;translate(-70.34765625,70.34765625)&#34; class=&#34;label-container&#34;&gt;&lt;/polygon&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-39.1640625,-19)&#34;&gt;&lt;foreignObject width=&#34;78.328125&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Broadcast&lt;br&gt;or Unicast?&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id4-33&#34; transform=&#34;translate(366.1609344482422,407.76953125)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;polygon points=&#34;60.84140625,0 121.6828125,-60.84140625 60.84140625,-121.6828125 0,-60.84140625&#34; transform=&#34;translate(-60.84140625,60.84140625)&#34; class=&#34;label-container&#34;&gt;&lt;/polygon&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-38.1015625,-9.5)&#34;&gt;&lt;foreignObject width=&#34;76.203125&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Broadcast?&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id5-38&#34; transform=&#34;translate(112.671875,645.9343719482422)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;rect rx=&#34;29&#34; ry=&#34;29&#34; x=&#34;-104.671875&#34; y=&#34;-29&#34; width=&#34;209.34375&#34; height=&#34;58&#34; class=&#34;label-container&#34;&gt;&lt;/rect&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-87.421875,-19)&#34;&gt;&lt;foreignObject width=&#34;174.84375&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Simulate TopoCast using&lt;br&gt;singlehop configuration.&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id6-41&#34; transform=&#34;translate(366.1609344482422,645.9343719482422)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;polygon points=&#34;98.8171875,0 197.634375,-98.8171875 98.8171875,-197.634375 0,-98.8171875&#34; transform=&#34;translate(-98.8171875,98.8171875)&#34; class=&#34;label-container&#34;&gt;&lt;/polygon&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-70.796875,-19)&#34;&gt;&lt;foreignObject width=&#34;141.59375&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Simple transmission&lt;br&gt;model?&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id7-44&#34; transform=&#34;translate(218.50390625,943.0421752929688)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;rect rx=&#34;29&#34; ry=&#34;29&#34; x=&#34;-116.0234375&#34; y=&#34;-29&#34; width=&#34;232.046875&#34; height=&#34;58&#34; class=&#34;label-container&#34;&gt;&lt;/rect&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-98.7734375,-19)&#34;&gt;&lt;foreignObject width=&#34;197.546875&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Simulate transmission using&lt;br&gt;simpleMultihopDelay.&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id8-47&#34; transform=&#34;translate(513.8179626464844,943.0421752929688)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;polygon points=&#34;129.290625,0 258.58125,-129.290625 129.290625,-258.58125 0,-129.290625&#34; transform=&#34;translate(-129.290625,129.290625)&#34; class=&#34;label-container&#34;&gt;&lt;/polygon&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-104.65625,-19)&#34;&gt;&lt;foreignObject width=&#34;209.3125&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Sender directly able to reach&lt;br&gt;destination area?&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id9-50&#34; transform=&#34;translate(360.3570251464844,1170.3327941894531)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;rect rx=&#34;19.5&#34; ry=&#34;19.5&#34; x=&#34;-115.109375&#34; y=&#34;-19.5&#34; width=&#34;230.21875&#34; height=&#34;39&#34; class=&#34;label-container&#34;&gt;&lt;/rect&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-100.234375,-9.5)&#34;&gt;&lt;foreignObject width=&#34;200.46875&#34; height=&#34;19&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Flooding in destination area&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g class=&#34;node default&#34; id=&#34;flowchart-id10-53&#34; transform=&#34;translate(667.2789001464844,1170.3327941894531)&#34; style=&#34;opacity: 1;&#34;&gt;&lt;rect rx=&#34;29&#34; ry=&#34;29&#34; x=&#34;-141.8125&#34; y=&#34;-29&#34; width=&#34;283.625&#34; height=&#34;58&#34; class=&#34;label-container&#34;&gt;&lt;/rect&gt;&lt;g class=&#34;label&#34; transform=&#34;translate(0,0)&#34;&gt;&lt;g transform=&#34;translate(-124.5625,-19)&#34;&gt;&lt;foreignObject width=&#34;249.125&#34; height=&#34;38&#34;&gt;&lt;div xmlns=&#34;http://www.w3.org/1999/xhtml&#34; style=&#34;display: inline-block; white-space: nowrap;&#34;&gt;Greedy Forwarding to reach area,&lt;br&gt;then flooding in destination areay.&lt;/div&gt;&lt;/foreignObject&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/svg&gt;
   &lt;/div&gt;

     &lt;div class=&#34;desc&#34;&gt;
       This flowchart tells how different types of messages are handled internally.
     &lt;/div&gt;

 &lt;/div&gt;


 &lt;h3 id=&#34;topocasts&#34;&gt;TopoCasts&lt;/h3&gt;
 &lt;p&gt;The only way of directly addressing entities is a &lt;em&gt;SingleHopUniCast&lt;/em&gt; (see figure below), the sender will try to address an entity
 in its transmission range.


 &lt;figure id=&#34;figure-singlehopunicast-the-rsu-is-directly-addressing-the-green-vehicle&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/SingleHopUniCast.png&#34; data-caption=&#34;SingleHopUniCast: The RSU is directly addressing the green vehicle.&#34;&gt;


   &lt;img src=&#34;../images/SingleHopUniCast.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     SingleHopUniCast: The RSU is directly addressing the green vehicle.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 The counterpart to that is a &lt;em&gt;SingleHopBroadCast&lt;/em&gt; (see figure below), this form of transmission is commonly used for CAMs (Cooperative Awareness Messages)
 and other types of intermediate warning messages to all entities in transmission range.&lt;br&gt;


 &lt;figure id=&#34;figure-singlehopbroadcast-the-rsu-is-addressing-all-units-in-transmission-range&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/SingleHopBroadCast.png&#34; data-caption=&#34;SingleHopBroadCast: The RSU is addressing all units in transmission range.&#34;&gt;


   &lt;img src=&#34;../images/SingleHopBroadCast.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     SingleHopBroadCast: The RSU is addressing all units in transmission range.
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/p&gt;
 &lt;h3 id=&#34;geocasts&#34;&gt;GeoCasts&lt;/h3&gt;
 &lt;p&gt;As already explained, GeoCasts do not support direct addressing, so there is no form of UniCast. Instead of addressing
 entities, GeoCasts specify a destination area in which a message should be distributed.
 The SNS supports two ways to simulate GeoCasts.
 A simple but performant model (&lt;code&gt;SimpleAdhocTransmissionModel&lt;/code&gt;) &amp;amp; a fairly realistic model ( &lt;code&gt;SophisticatedAdhocTransmissionModel&lt;/code&gt;).&lt;/p&gt;
 &lt;p&gt;The simple model assumes a transmission to all entities in the specified area, whereas the delay will be calculated using the configured delay-type and the successful reception will be determined by the uniformly distributed lossProbability.
 The figure below depicts this behaviour


 &lt;figure id=&#34;figure-simple-geobroadcast-the-rsu-is-sending-to-all-entities-in-the-destination-area-all-arrows-transmissions-will-have-a-uniquely-calculated-delay-or-possible-loss&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/SimpleMultiHop.png&#34; data-caption=&#34;Simple GeoBroadCast: The RSU is sending to all entities in the destination area. All arrows (transmissions) will have a uniquely calculated delay or possible loss.&#34;&gt;


   &lt;img src=&#34;../images/SimpleMultiHop.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     Simple GeoBroadCast: The RSU is sending to all entities in the destination area. All arrows (transmissions) will have a uniquely calculated delay or possible loss.
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/p&gt;
 &lt;p&gt;The realistic model accounts for possible transmission failures more accurately. The easiest case is that the sender itself is inside
 of the destination area&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt; and will start a
 &lt;a href=&#34;#flooding-transmission&#34;&gt;Flooding Transmission&lt;/a&gt; within this area (see figure below).


 &lt;figure id=&#34;figure-geobroadcast-using-flooding-transmissionflooding-transmission-note-the-area-is-not-limited-to-circles&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/FloodingTransmission.png&#34; data-caption=&#34;GeoBroadCast using Flooding Transmission. Note: the area is not limited to circles.&#34;&gt;


   &lt;img src=&#34;../images/FloodingTransmission.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     GeoBroadCast using &lt;a href=&#34;#flooding-transmission&#34;&gt;Flooding Transmission&lt;/a&gt;. Note: the area is not limited to circles.
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/p&gt;
 &lt;p&gt;In case the sending entity is outside of the destination area, a
 &lt;a href=&#34;#approaching-transmission&#34;&gt;Forwarding Transmission&lt;/a&gt; has to
 be executed first. This is can also be described as an &lt;em&gt;AnyCast&lt;/em&gt;, since the goal of this transmission is to reach &lt;em&gt;any&lt;/em&gt; entity
 inside the destination area. We try to achieve this by building a &amp;ldquo;chain&amp;rdquo; of entities, that will forward the message to the destination
 are (see figure below).


 &lt;figure id=&#34;figure-forwarding-transmission-by-building-a-chain-of-vehicles&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/ApproachingTransmission.png&#34; data-caption=&#34;Forwarding Transmission, by building a &amp;ldquo;chain&amp;rdquo; of vehicles.&#34;&gt;


   &lt;img src=&#34;../images/ApproachingTransmission.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     Forwarding Transmission, by building a &amp;ldquo;chain&amp;rdquo; of vehicles.
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/p&gt;
 &lt;p&gt;The SNS however never uses
 &lt;a href=&#34;#approaching-transmission&#34;&gt;Forwarding Transmissions&lt;/a&gt; individually, rather they are combined with a
 &lt;a href=&#34;#flooding-transmission&#34;&gt;Flooding Transmission&lt;/a&gt;, which
 will simulate a way, that GeaCasts can be implemented in reality. The figure below depicts this behaviour.


 &lt;figure id=&#34;figure-forwarding-transmission-followed-by-a-flooding-transmissionflooding-transmission-to-realistically-simulate-geocasts&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/ApproachingAndFlooding.png&#34; data-caption=&#34;Forwarding Transmission followed by a Flooding Transmission to realistically simulate GeoCasts.&#34;&gt;


   &lt;img src=&#34;../images/ApproachingAndFlooding.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     Forwarding Transmission followed by a &lt;a href=&#34;#flooding-transmission&#34;&gt;Flooding Transmission&lt;/a&gt; to realistically simulate GeoCasts.
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/p&gt;
 &lt;h2 id=&#34;transmission-models&#34;&gt;Transmission Models&lt;/h2&gt;
 &lt;p&gt;As already mentioned in the previous abstracts, the SNS supports different transmission models for different use cases.
 Depending on the configuration of the SNS and the type of message send, different models will be used.
 The models are located in the package &lt;code&gt;org.eclipse.mosaic.fed.sns.ambassador.model&lt;/code&gt;. This chapter aims to give
 a detailed inside in the workings of the models.&lt;/p&gt;
 &lt;h3 id=&#34;simpleadhoctransmissionmodel&#34;&gt;&lt;code&gt;SimpleAdhocTransmissionModel&lt;/code&gt;&lt;/h3&gt;
 &lt;p&gt;This is the most basic of all transmission models and will be your model of choice if you are not interested in completely
 accurate transmission results but care for performance. This model will approximate GeoCasts using the defined &lt;code&gt;simpleMultihopDelay&lt;/code&gt;
 and &lt;code&gt;simpleMultihopTransmission&lt;/code&gt; parameters.
 For TopoCasts the usual &lt;code&gt;singlehopDelay&lt;/code&gt; will be used.
 This model only checks, whether a potential receiver is inside the destination area and has enabled Adhoc capabilities.
 If those conditions are met it will simulate the transmission by calculating an actual delay value and saving it into a
 transmission-result. Such a result holds information of the success of the transmission, the delay-value, the amount of hops,
 and the number of attempts. Though the amount of hops will always be 1 for this model.&lt;/p&gt;
 &lt;h3 id=&#34;sophisticatedadhoctransmissionmodel&#34;&gt;&lt;code&gt;SophisticatedAdhocTransmissionModel&lt;/code&gt;&lt;/h3&gt;
 &lt;p&gt;This model offers are more realistic simulation of adhoc transmissions, using an implementation of a greedy-forwarding and flooding
 algorithm (see
 &lt;a href=&#34;https://en.wikipedia.org/wiki/Geographic_routing&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;here (greedy forwarding)&lt;/a&gt; &amp;amp;

 &lt;a href=&#34;https://en.wikipedia.org/wiki/Flooding_%28computer_networking%29&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;here (flooding)&lt;/a&gt;). For TopoCasts this model behaves very
 similarly to the &lt;code&gt;SimpleAdhocTransmissionModel&lt;/code&gt;, since TopoCasts are always configured with only one hop.
 For GeoCasts however, this model follows the flowchart above, trying to &amp;ldquo;approach&amp;rdquo; a destination area if it can&amp;rsquo;t be reached directly.&lt;/p&gt;
 &lt;h4 id=&#34;approaching-greedy-forwarding&#34;&gt;Approaching (Greedy forwarding)&lt;/h4&gt;
 &lt;p&gt;Approaching can be imagined as building a &amp;ldquo;chain&amp;rdquo; of entities to reach an area. However, there is no
 guarantee, that even if such a chain exists, it will be found. The way that this chain is build follows the subsequent steps:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Start from the sender and collect all reachable entities.&lt;/li&gt;
 &lt;li&gt;Choose out of all reachable entities the one, that is closest to any node in the destination area.&lt;/li&gt;
 &lt;li&gt;Use the chosen node and repeat the first step.&lt;/li&gt;
 &lt;li&gt;Repeat until either a node inside the destination area is reached, or the TTL (time to live) is exceeded.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;By always choosing the node with the shortest distance to the destination area, we omit a lot of possible solutions.
 Greedy Forwarding isn&amp;rsquo;t optimal, but offers a performant approach for this problem. &amp;ldquo;Face Routing&amp;rdquo;-algorithms will always
 find a path if one exists, however this hasn&amp;rsquo;t been implemented yet (feel free to contribute :).
 The figure below shows an example of those shortcomings, the message will be send using the green nodes and won&amp;rsquo;t receive the destination
 area, even though there is a possible &amp;ldquo;chain&amp;rdquo; using the yellow nodes.&lt;/p&gt;


 &lt;div class=&#34;svg-wrap mt-1 mb-4&#34;&gt;
   &lt;div class=&#34;inner&#34;&gt;
     &lt;?xml version=&#34;1.0&#34; encoding=&#34;UTF-8&#34; standalone=&#34;no&#34;?&gt;
 &lt;svg
    xmlns:dc=&#34;http://purl.org/dc/elements/1.1/&#34;
    xmlns:cc=&#34;http://creativecommons.org/ns#&#34;
    xmlns:rdf=&#34;http://www.w3.org/1999/02/22-rdf-syntax-ns#&#34;
    xmlns:svg=&#34;http://www.w3.org/2000/svg&#34;
    xmlns=&#34;http://www.w3.org/2000/svg&#34;
    xmlns:sodipodi=&#34;http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd&#34;
    xmlns:inkscape=&#34;http://www.inkscape.org/namespaces/inkscape&#34;
    width=&#34;100%&#34;
    height=&#34;100%&#34;
    viewBox=&#34;0 0 1000 1100&#34;
    preserveAspectRatio=&#34;xMinYMin meet&#34;
    version=&#34;1.1&#34;
    id=&#34;svg112&#34;
    sodipodi:docname=&#34;shortcomingsApproaching.svg&#34;
    inkscape:version=&#34;0.92.4 (5da689c313, 2019-01-14)&#34;&gt;
   &lt;metadata
      id=&#34;metadata116&#34;&gt;
     &lt;rdf:RDF&gt;
       &lt;cc:Work
          rdf:about=&#34;&#34;&gt;
         &lt;dc:format&gt;image/svg+xml&lt;/dc:format&gt;
         &lt;dc:type
            rdf:resource=&#34;http://purl.org/dc/dcmitype/StillImage&#34; /&gt;
         &lt;dc:title&gt;&lt;/dc:title&gt;
       &lt;/cc:Work&gt;
     &lt;/rdf:RDF&gt;
   &lt;/metadata&gt;
   &lt;sodipodi:namedview
      pagecolor=&#34;#ffffff&#34;
      bordercolor=&#34;#000000&#34;
      borderopacity=&#34;1&#34;
      objecttolerance=&#34;10&#34;
      gridtolerance=&#34;10&#34;
      guidetolerance=&#34;10&#34;
      inkscape:pageopacity=&#34;0&#34;
      inkscape:pageshadow=&#34;2&#34;
      inkscape:window-width=&#34;2560&#34;
      inkscape:window-height=&#34;1377&#34;
      id=&#34;namedview114&#34;
      showgrid=&#34;false&#34;
      inkscape:zoom=&#34;0.54909091&#34;
      inkscape:cx=&#34;70.460088&#34;
      inkscape:cy=&#34;483.05537&#34;
      inkscape:window-x=&#34;1912&#34;
      inkscape:window-y=&#34;-8&#34;
      inkscape:window-maximized=&#34;1&#34;
      inkscape:current-layer=&#34;g110&#34; /&gt;
   &lt;defs
      id=&#34;defs66&#34;&gt;
     &lt;clipPath
        id=&#34;EGXEKOJWuGVn&#34;&gt;
       &lt;path
          id=&#34;svg_1&#34;
          d=&#34;m0,0l1673,0l0,1285l-1673,0l0,-1285z&#34;
          fill=&#34;none&#34; /&gt;
     &lt;/clipPath&gt;
   &lt;/defs&gt;
   &lt;g
      id=&#34;g110&#34;&gt;
     &lt;title
        id=&#34;title68&#34;&gt;Layer 1&lt;/title&gt;
     &lt;path
        style=&#34;fill:#ffd700;fill-opacity:0.3&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 460.74242,186.92776 c 0,75.84645 -61.4857,137.33215 -137.33215,137.33215 -75.84645,0 -137.33215,-61.4857 -137.33215,-137.33215 0,-75.84645 61.4857,-137.332153 137.33215,-137.332153 75.84645,0 137.33215,61.485703 137.33215,137.332153 z&#34;
        id=&#34;svg_5&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#caab06;stroke-width:2.5;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 460.74242,186.92776 c 0,75.84645 -61.4857,137.33215 -137.33215,137.33215 -75.84645,0 -137.33215,-61.4857 -137.33215,-137.33215 0,-75.84645 61.4857,-137.332153 137.33215,-137.332153 75.84645,0 137.33215,61.485703 137.33215,137.332153 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_6&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:#ffd700&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;229.62225&#34;
        y=&#34;37.811882&#34;
        id=&#34;svg_7&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Destination Area&lt;/text&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:none;stroke:#ffffff;stroke-width:3;stroke-linejoin:bevel;stroke-miterlimit:10&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;229.62225&#34;
        y=&#34;37.811882&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_8&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Destination Area&lt;/text&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:#978006;stroke:none;stroke-opacity:1;&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;229.62225&#34;
        y=&#34;37.811882&#34;
        id=&#34;svg_9&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Destination Area&lt;/text&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 529.40849,873.5885 c 0,113.7697 -92.22855,205.9982 -205.99822,205.9982 -113.76968,0 -205.99822,-92.2285 -205.99822,-205.9982 0,-113.76967 92.22854,-205.99822 205.99822,-205.99822 113.76967,0 205.99822,92.22855 205.99822,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_10&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 486.82048,688.91189 c 0,113.76968 -92.22854,205.99822 -205.99822,205.99822 -113.76968,0 -205.99822,-92.22854 -205.99822,-205.99822 0,-113.76968 92.22854,-205.99822 205.99822,-205.99822 113.76968,0 205.99822,92.22854 205.99822,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_11&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 428.82048,511.91189 c 0,113.76968 -92.22854,205.99822 -205.99822,205.99822 -113.76968,0 -205.99822,-92.22854 -205.99822,-205.99822 0,-113.76968 92.22854,-205.99822 205.99822,-205.99822 113.76968,0 205.99822,92.22854 205.99822,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_12&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 696.92801,775.58689 c 0,113.76968 -92.2286,205.99821 -205.99825,205.99821 -113.76968,0 -205.99822,-92.22853 -205.99822,-205.99821 0,-113.76968 92.22854,-205.99822 205.99822,-205.99822 113.76965,0 205.99825,92.22854 205.99825,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_13&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 846.82051,657.91189 c 0,113.76968 -92.2286,205.99822 -205.9982,205.99822 -113.76973,0 -205.99827,-92.22854 -205.99827,-205.99822 0,-113.76968 92.22854,-205.99822 205.99827,-205.99822 113.7696,0 205.9982,92.22854 205.9982,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_14&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 988.82051,527.91189 c 0,113.76968 -92.2286,205.99822 -205.9982,205.99822 -113.7697,0 -205.99827,-92.22854 -205.99827,-205.99822 0,-113.76968 92.22857,-205.99822 205.99827,-205.99822 113.7696,0 205.9982,92.22854 205.9982,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_15&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 941.82051,347.91189 c 0,113.76968 -92.2286,205.99822 -205.9982,205.99822 -113.7697,0 -205.99827,-92.22854 -205.99827,-205.99822 0,-113.76968 92.22857,-205.99822 205.99827,-205.99822 113.7696,0 205.9982,92.22854 205.9982,205.99822 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_16&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-width:0.5;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:8.5, 8;stroke-opacity:0.69803999&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 783.82051,235.91189 c 0,113.76968 -92.2286,205.99822 -205.99825,205.99822 -113.76968,0 -205.99822,-92.22854 -205.99822,-205.99822 0,-113.76968 92.22854,-205.998223 205.99822,-205.998223 113.76965,0 205.99825,92.228543 205.99825,205.998223 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_17&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#1565c0&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 332.41027,873.5885 c 0,4.97057 -4.02944,9 -9,9 -4.97056,0 -9,-4.02943 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_18&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 332.41027,873.5885 c 0,4.97057 -4.02944,9 -9,9 -4.97056,0 -9,-4.02943 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_19&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:#1565c0&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;293.62225&#34;
        y=&#34;854.81189&#34;
        id=&#34;svg_20&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Sender&lt;/text&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:none;stroke:#ffffff;stroke-width:3;stroke-linejoin:bevel;stroke-miterlimit:10&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;293.62225&#34;
        y=&#34;854.81189&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_21&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Sender&lt;/text&gt;
     &lt;text
        style=&#34;font-style:normal;font-weight:normal;font-size:20px;font-family:geogebra-sans-serif, sans-serif;text-anchor:start;fill:#1565c0;stroke:none;stroke-opacity:1;&#34;
        font-size=&#34;20px&#34;
        font-style=&#34;normal&#34;
        font-weight=&#34;normal&#34;
        x=&#34;293.62225&#34;
        y=&#34;854.81189&#34;
        id=&#34;svg_22&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34;&gt;Sender&lt;/text&gt;
     &lt;path
        style=&#34;fill:#ffd700&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 649.82231,657.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_23&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 649.82231,657.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_24&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#ffd700&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 791.82231,527.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_25&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 791.82231,527.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_26&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#006633&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 289.82226,688.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_27&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 289.82226,688.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_28&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#993300&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 310.87082,296.76468 c 0,4.97056 -4.02944,9 -9,9 -4.97057,0 -9,-4.02944 -9,-9 0,-4.97056 4.02943,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_29&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 310.87082,296.76468 c 0,4.97056 -4.02944,9 -9,9 -4.97057,0 -9,-4.02944 -9,-9 0,-4.97056 4.02943,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_30&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#993300&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 415.68715,197.27798 c 0,4.97057 -4.02943,9 -9,9 -4.97056,0 -9,-4.02943 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97057,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_31&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 415.68715,197.27798 c 0,4.97057 -4.02943,9 -9,9 -4.97056,0 -9,-4.02943 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97057,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_32&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#993300&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 319.75356,156.41738 c 0,4.97056 -4.02944,9 -9,9 -4.97057,0 -9,-4.02944 -9,-9 0,-4.97056 4.02943,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_33&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 319.75356,156.41738 c 0,4.97056 -4.02944,9 -9,9 -4.97057,0 -9,-4.02944 -9,-9 0,-4.97056 4.02943,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_34&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#006400&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 231.82226,511.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_35&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 231.82226,511.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_36&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#ffd700&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 499.92976,775.58689 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_37&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 499.92976,775.58689 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_38&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#ffd700&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 744.82231,347.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_39&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 744.82231,347.91189 c 0,4.97056 -4.0295,9 -9,9 -4.9706,0 -9,-4.02944 -9,-9 0,-4.97056 4.0294,-9 9,-9 4.9705,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_40&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:#ffd700&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 586.82226,235.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        id=&#34;svg_41&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
     &lt;path
        style=&#34;fill:none;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10&#34;
        inkscape:connector-curvature=&#34;0&#34;
        d=&#34;m 586.82226,235.91189 c 0,4.97056 -4.02944,9 -9,9 -4.97056,0 -9,-4.02944 -9,-9 0,-4.97056 4.02944,-9 9,-9 4.97056,0 9,4.02944 9,9 z&#34;
        stroke-miterlimit=&#34;10&#34;
        id=&#34;svg_42&#34;
        inkscape:export-xdpi=&#34;96&#34;
        inkscape:export-ydpi=&#34;96&#34; /&gt;
   &lt;/g&gt;
 &lt;/svg&gt;

   &lt;/div&gt;

     &lt;div class=&#34;desc&#34;&gt;
       This figure depicts a case were the Approaching Transmission wouldn&amp;rsquo;t reach the destination area, even though there is a possible way. (The dashed lines represent the communication range)
     &lt;/div&gt;

 &lt;/div&gt;


 &lt;h4 id=&#34;flooding&#34;&gt;Flooding&lt;/h4&gt;
 &lt;p&gt;The implementation of Flooding is fairly equivalent as described on

 &lt;a href=&#34;https://en.wikipedia.org/wiki/Flooding_%28computer_networking%29&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;wikipedia&lt;/a&gt;. Each entity forwards the message to all entities
 in its communication range. Entities, that already received the message won&amp;rsquo;t receive it again; this is different from many real-life
 implementations, where messages are send to all reachable entities except the sender. However, since the simulation has total
 knowledge of all simulated entities, it is easier to overcome a lot of the disadvantages, that flooding faces
 in real world implementations.&lt;/p&gt;
 &lt;h4 id=&#34;implementing-your-own-adhoctransmissionmodel&#34;&gt;Implementing your own &lt;code&gt;AdhocTransmissionModel&lt;/code&gt;&lt;/h4&gt;
 &lt;p&gt;If the implemented models don&amp;rsquo;t suffice your needs you can easily implement your own.
 Create a class extending &lt;code&gt;AdhocTransmissionModel&lt;/code&gt; and implement the abstract methods for sending TopoCasts/GeoCasts.
 A possible extension could be to allow for multihop TopoCasts, building an actual topology and transmit your
 messages using that topology. Also, the aforementioned &amp;ldquo;Face-Routing&amp;rdquo; could be of interest. Additionally, the calculation
 of delays could be made more realistic.&lt;/p&gt;
 &lt;h2 id=&#34;accessing-sns-functionality-from-your-applications&#34;&gt;Accessing SNS-functionality from your applications&lt;/h2&gt;
 &lt;p&gt;In order for your scenario to enable the SNS follow the steps
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_configuration/#communication-simulators-cell-ns3-omnetpp-sns&#34;&gt;here&lt;/a&gt;.
 An overview of how to configure AdHoc-modules and usage of the API for Routing and Message-Building functions,
 can be found
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/communication/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
 &lt;section class=&#34;footnotes&#34; role=&#34;doc-endnotes&#34;&gt;
 &lt;hr&gt;
 &lt;ol&gt;
 &lt;li id=&#34;fn:1&#34; role=&#34;doc-endnote&#34;&gt;
 &lt;p&gt;Or is able to communicate with an entity inside the destination area. &lt;a href=&#34;#fnref:1&#34; class=&#34;footnote-backref&#34; role=&#34;doc-backlink&#34;&gt;&amp;#x21a9;&amp;#xfe0e;&lt;/a&gt;&lt;/p&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;/section&gt;
 </description>
     </item>

     <item>
       <title>OMNeT&#43;&#43; Federate Implementation</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/omnetpp_details/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/omnetpp_details/</guid>
       <description>&lt;p&gt;The OMNeT++ Federate design is based on amicrosimulation where every participating vehicle respectively
 node is individually modeled and simulated and all entities are clued together in a scenario with
 one instance the manages the interaction between them. That means at first the internals of one node
 are introduced which incorporate mainly the communication stack and a mobilitymodel. Afterwards,
 especially the scenario management is presented which builds up on the individual nodes and controls
 themajor part of the simulation. These both aspects are in similar way needed formost mobile communication
 simulation with OMNeT++ even in an isolated setup. However, specifically for interaction and
 synchronization with the other simulators in the Eclipse MOSAIC environment, a third pillar is necessary. This
 scheduler module is very important for the system as it implements the time management and event
 scheduling according to Eclipse MOSAIC specific concepts.&lt;/p&gt;
 &lt;h3 id=&#34;node-internals&#34;&gt;Node Internals&lt;/h3&gt;
 &lt;p&gt;The main part of the node model consists of the communication stack. The submodules for communication
 are adopted from the INETMANET framework. Hence, it is primarily important to define the
 connections between the individual modules. However, there are also modules which needed to be
 implemented for the dedicated purpose of the coupling within the Eclipse MOSAIC environment. Finally, all
 modules are linked together to a compound module using the NED language. The following figure depicts the node architecture. It needs to be said that the concept currently supports two different
 kinds of nodes for Vehicles and RSUs, while V2X-based traffic lights are treated as RSUs. For the first
 approach these two kinds of nodes have the equal construction in terms of modules. The difference at the
 moment is that they can be configured with different values for parameters e.g. that Vehicles and RSUs
 have a different antenna height which is important for Two Ray Ground ReflectionModel. Furthermore,
 this concept is capable for later extensions e.g. for simulations when RSUs should be equipped with an
 additional network interface to build the bridge fromAd hoc Domain to the Fixed Infrastructure Domain
 (i.e. Internet).&lt;/p&gt;


 &lt;figure id=&#34;figure-architecture-of-one-node&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/implementation_simcoupling.jpeg&#34; data-caption=&#34;Architecture of one Node&#34;&gt;


   &lt;img src=&#34;../images/implementation_simcoupling.jpeg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Architecture of one Node
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h5 id=&#34;communication-stack&#34;&gt;Communication Stack&lt;/h5&gt;
 &lt;p&gt;The right part of the block diagram in the figure above depicts the communication stack. It is based on the
 module Wlan which is a compound module itself and covers the complete IEEE 802.11 network interface
 card with the MAC and PHY Layer and the Radio Channel. The configuration of different values for
 standard parameters e.g. the PHY bit rate or size of the contention window of the MAC can be exchanged
 within the omnetpp.ini-file (which introduces the parameters of the according module ned-files). Please
 note that the configuration allows different values for each kind of nodes and hence it is possible to
 configure another propagation model or carrier frequency for Vehicles compared to RSUs. Even if
 the possibility for such a configuration exists, it should be avoided and common parameters should
 consistently be configured twice with the same value.&lt;/p&gt;
 &lt;p&gt;The next module in the communication stack is the NetworkLayer. Once again it is a compound module
 and already a collection of most important protocols. The following protocols from version IPv4 are
 supported in this layer.&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;IP (Internet Protocol) of course as primary protocol of the Network Layer&lt;/li&gt;
 &lt;li&gt;ICMP (Internet ControlMessage Protocol) for information and error messages&lt;/li&gt;
 &lt;li&gt;IGMP (Internet GroupManagement Protocol) for management ofmulticast functionality&lt;/li&gt;
 &lt;li&gt;ARP (Address Resolution Protocol) for mapping of IP Addresses toMAC Addresses&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;Furthermore, the standalone modules InterfaceTable and RoutingTable are related to the Network
 Layer. The first one is needed to support multiple Network Interface Cards e.g. for wireless and fixed LAN
 in one node. It is already included for possible further extensions as previously mentioned, but up to
 now it has only one entry which is the Network Interface Card for Wlan. The second one is a table for
 simple Routing. This module is needed for correct instantiation of a node via the FlatNetworkGenerator
 as explained later in this section.&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;TransportLayer&lt;/code&gt; of the communication stack is made up of TCP for reliable connections and UDP.&lt;/p&gt;
 &lt;p&gt;The modules &lt;code&gt;VSimRTIReliableApp&lt;/code&gt; and &lt;code&gt;VSimRTIUnreliableApp&lt;/code&gt; of Application Layer are the entry
 points for application messages for the communication stack for the following reasons. The communication
 oriented models of INETMANET have their focus more on the framing for communication and less on
 the real content. That means that content is often modeled with dummy payloads where only the length is
 of interest. In contrast, V2X applications which are simulated in the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/application_simulator/&#34;&gt;Application Simulator&lt;/a&gt;.
 Rely on the correct transmission of contents. Hence, the modules &lt;code&gt;VSimRTIReliableApp&lt;/code&gt; and &lt;code&gt;VSimRTIUnreliableApp&lt;/code&gt;
 are introduced to bridge this gap. They are triggered by the Eclipse MOSAIC ScenarioManager
 to send new messages to lower layers and forward messages themselves back to the ScenarioManager
 upon reception. The main tasks are generally acting as an application within the scope of OMNeT++ and
 encapsulating themessage contents to packets to prepare them for sending. While functionality of an
 UDP application is fully supported in &lt;code&gt;VSimRTIUnreliableApp&lt;/code&gt;, the complete TCP application functionality
 is restricted in &lt;code&gt;VSimRTIReliableApp&lt;/code&gt;. Note that up to now it is not entirely clarified if and how TCP should
 be supported in V2X use cases for safety and traffic efficiency with their broadcast characteristics, think
 of different roles of server and client in TCP. When the Eclipse MOSAIC ScenarioManager properties are detailed
 later in this section, it is also explained how the connection between the Eclipse MOSAIC ScenarioManager and
 the Eclipse MOSAIC Apps is realized. This connection needs to be established dynamically and is therefore not
 assigned with a connecting arrow like the fixed connections between the modules of communication
 stack.&lt;/p&gt;
 &lt;h5 id=&#34;mobility-model&#34;&gt;Mobility Model&lt;/h5&gt;
 &lt;p&gt;The second important component of the node is the mobility module &lt;code&gt;VSimRTIMobility&lt;/code&gt;, which extends
 the BasicMobility. Unlike other mobility models as RandomWaypoint it does not generate node movements
 itself and has a straight static character. Node position updates are always triggered by the Eclipse MOSAIC
 ScenarioManager. Hence,mobility is completely controlled by Eclipse MOSAIC and in turn by the coupled traffic
 simulator. After successful position update the &lt;code&gt;VSimRTIMobility&lt;/code&gt; module informs other modules about
 this event via the NotificationBoard.&lt;/p&gt;
 &lt;h5 id=&#34;additional-functionality&#34;&gt;Additional Functionality&lt;/h5&gt;
 &lt;p&gt;At last, the module NotificationBoard is defined for each node. This module was already mentioned in
 the model overview of INETMANET. It enables a very efficient way for dynamic communication between
 the individual modules. There is no direct and static connection needed between the modules, because
 modules can subscribe dynamically for notification about dedicated events.&lt;/p&gt;
 &lt;h3 id=&#34;simulation-setup&#34;&gt;Simulation Setup&lt;/h3&gt;
 &lt;p&gt;The setup of the complete simulation is illustrated in the following Figure 3 From the view of OMNeT++,
 the simulation is a network which has a dynamic topology and is referenced as the simulated network
 in the omnetpp.ini-file for configuration. The ini-file gives access to all parameters which are offered
 to be configured by the included simple modules. The parameters are referred to by their hierarchical
 names with the simulated network as root module. As it is possible to assign already default values for
 parameters in the modules NED file, not every parameter needs to be configured in the ini-file. The
 simulation consists of basically three parts.&lt;/p&gt;


 &lt;figure id=&#34;figure-architecture-of-the-whole-simulation-scenario&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/implementation_simulation.jpeg&#34; data-caption=&#34;Architecture of the whole Simulation Scenario&#34;&gt;


   &lt;img src=&#34;../images/implementation_simulation.jpeg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Architecture of the whole Simulation Scenario
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h5 id=&#34;simulated-nodes&#34;&gt;Simulated Nodes&lt;/h5&gt;
 &lt;p&gt;Obviously the major part of the simulation is dedicated to the nodes. They are compound modules either
 from type Vehicle or RSU and have the properties as described in the previous section. The number
 of nodes in the simulation can vary over simulation time and is dynamically managed by the Eclipse MOSAIC
 ScenarioManager.&lt;/p&gt;
 &lt;h5 id=&#34;common-communication-dependent-modules&#34;&gt;Common Communication Dependent Modules&lt;/h5&gt;
 &lt;p&gt;The second part covers the modules which actually count to the communication stack, but are common
 for all simulated nodes. These modules are the ChannelControl and the FlatNetworkGenerator.
 The ChannelControl keeps track of all nodes, their positions and Radio Channels. The main task is to
 determine which nodes are in communication range and which other nodes are within interference
 distance. The FlatNetworkGenerator is part of the Network Layer. It is used to instantiate a network
 with a flat topology and assigns the IP addresses to all nodes. Additionally it runs Dijstra’s shortest path
 algorithm to discover the routes and adds them into the routing tables. It is assumed that the routing
 tables are of kind of the RoutingTable from the specific NetworkLayer package. This is the reason why
 every node is equipped with the RoutingTable submodule. This approach works out for the current
 simulation purposes, but when any Ad hoc Routing protocols will be introduced to the simulation model
 the FlatNetworkGenerator and the RoutingTable modules are likely be obsolete and would have to be
 replaced.&lt;/p&gt;
 &lt;h5 id=&#34;eclipse-mosaic-scenariomanager&#34;&gt;Eclipse MOSAIC ScenarioManager&lt;/h5&gt;
 &lt;p&gt;The &lt;code&gt;ScenarioManager&lt;/code&gt; is an experimental feature that implements a central control instance in
 simulations with INETMANET framework. It is loaded with a script in XML notation and is used to setup and control simulation experiments. Actually the original ScenarioManager and the new
 Eclipse MOSAIC ScenarioManager have nearly nothing in common but the fact that both are used as a central
 management instance to enhance simple configurations to simulate more sophisticated scenarios. The
 general tasks of the Eclipse MOSAIC ScenarioManager contain the simulation start up with instantiation of
 common modules as ChannelControl and initialization of the Eclipse MOSAIC EventScheduler (detailed later)
 and the controlled simulation shut down. But most important beside these are the management of node
 mobility and management of V2X communication which are triggered by Eclipse MOSAIC during simulation.&lt;/p&gt;
 &lt;p&gt;The &lt;strong&gt;Mobility Management&lt;/strong&gt; is responsible for administration of simulated nodes and their mobility.
 This includes introducing nodes to simulation, updating node positions and removing nodes from
 simulation.&lt;/p&gt;
 &lt;p&gt;The node introduction method is triggered by Eclipse MOSAIC with the commands &lt;code&gt;ADD_NODES&lt;/code&gt; or &lt;code&gt;ADD_RSU_NODES&lt;/code&gt; respectively. It adds the node according to its node id to the managed modules and creates the complete compound module. Important for later message handling is the setup of connections to the dedicated Eclipse MOSAIC App, which is done via so called gates. At the moment, the Eclipse MOSAIC Apps are statically initialized, but the concept is suitable to be extended later when other transport protocols and in turn
 applications have to be simulated.&lt;/p&gt;
 &lt;p&gt;Upon &lt;code&gt;MOVE_NODE&lt;/code&gt; command, which contains the affected node id and new position to be updated, the
 node is moved via the &lt;code&gt;VSimRTIMobility&lt;/code&gt; module.&lt;/p&gt;
 &lt;p&gt;At last the &lt;code&gt;REMOVE_NODE&lt;/code&gt; command indicates that a node leaves the simulation. On this event, the according node is deleted and unregistered from managed modules.&lt;/p&gt;
 &lt;p&gt;The &lt;strong&gt;CommunicationManagement&lt;/strong&gt; controls the sending and receiving of V2X messages.&lt;/p&gt;
 &lt;p&gt;The &lt;code&gt;SEND_V2X_MESSAGE&lt;/code&gt; command initiates the sending process. It contains the sender node id and
 the transport protocol. Thus the Eclipse MOSAIC ScenarioManager can select the according Eclipse MOSAIC app at the according node.&lt;/p&gt;
 &lt;p&gt;When a message from another node successfully arrives at the application layer the Eclipse MOSAIC ScenarioManager
 is notified by the according node. Then, it sets up a &lt;code&gt;RECV_V2X_MESSAGE&lt;/code&gt; which is sent back
 to Eclipse MOSAIC via the Eclipse MOSAIC EventScheduler. This intermediate step is introduced, since the Eclipse MOSAIC
 EventScheduler is the only instance, which is connected to Eclipse MOSAIC and which knows when it is safe to
 receive and send interactions.&lt;/p&gt;
 &lt;h3 id=&#34;simulator-coupling&#34;&gt;Simulator Coupling&lt;/h3&gt;
 &lt;p&gt;OMNeT++ is connected to Eclipse MOSAIC according to the concept of high-level-architecture (HLA). That
 means that the OMNeT++ simulation program itself is encapsulated in the OMNeT++ federate. To
 enable the coupling according to Eclipse MOSAIC concept, two components needed to be developed. First, the
 OMNeT++ federate is extended with the customized Eclipse MOSAIC EventScheduler, which can receive and
 send interactions forMobility and CommunicationManagement. The second component is the OMNeT++
 Ambassador that can handle on the one hand the OMNeT++ specific connection and on the other
 hand the well-defined interface to Eclipse MOSAIC. The emphasis of both components lies in the synchronized
 exchange of interactions i.e. a time management mechanism must be jointly realized by them. For this
 purpose the conservative synchronization mechanism is implemented. The following figure gives an overview
 of the included compenents.&lt;/p&gt;


 &lt;figure id=&#34;figure-overview-of-simulator-coupling&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/implementation_vehicle.jpeg&#34; data-caption=&#34;Overview of Simulator Coupling&#34;&gt;


   &lt;img src=&#34;../images/implementation_vehicle.jpeg&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Overview of Simulator Coupling
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h5 id=&#34;eclipse-mosaic-eventscheduler&#34;&gt;Eclipse MOSAIC EventScheduler&lt;/h5&gt;
 &lt;p&gt;The Eclipse MOSAIC EventScheduler extends the simple standard scheduler of OMNeT++ to be able to implement the time management for the Conservative Synchronization with Eclipse MOSAIC. It is the only module in OMNeT++ which has access to the event queue or Future Event Set (FES). Since the OMNeT++ simulation
 is an event driven simulation the scheduler has to fulfill two tasks. The first task is the actual scheduling
 part which is always invoked by the simulation kernel to schedule the next event. It allows all events from
 the FES to be processed up to the granted logical time $T$. If there are only events with a later time $T&#39;$ than
 $T$ left in the FES, it sends the Next Event Request (NER) to the OMNeT++ Ambassador at Eclipse MOSAIC side and
 blocks the OMNeT++ simulation. Then the second task comes into operation. If necessary, it coordinates
 the Receive Interaction procedure and merges the external events from Eclipse MOSAIC and hence from other
 federates to the internal FES. Events with the same time stamp are ordered to the FES according to first
 come first serve mechanism. Note that the handling of these simultaneous events is generally important
 to ensure repeatable execution of simulations. The decision about ordering is in control of the federate
 itself, since the RTI does not sufficiently have the information to do this. After the Receive Interaction
 step, the RTI completes the time management cycle with the Time Advance Grant for $T&#39;$. At this point the
 scheduler can set its logical time to $T = T&#39;$ and unblock the further processing.&lt;/p&gt;
 &lt;p&gt;Additionally the Eclipse MOSAIC EventScheduler provides the service for other modules to send interactions back
 to the OMNeT++ Ambassador, since it is also the one module which is connected to Eclipse MOSAIC. Currently,
 this is used by the Eclipse MOSAIC ScenarioManager to report the &lt;code&gt;RECEIVE_V2X_MESSAGES&lt;/code&gt;.&lt;/p&gt;
 &lt;h4 id=&#34;eclipse-mosaic-omnet-federate-development&#34;&gt;Eclipse MOSAIC OMNeT++ Federate Development&lt;/h4&gt;
 &lt;p&gt;This section provides a description how to set up the &lt;strong&gt;OMNeT++ IDE&lt;/strong&gt; for the Eclipse MOSAIC OMNeT++ Federate Development.&lt;/p&gt;
 &lt;p&gt;At this point it is awaited, that the
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/&#34;&gt;OMNeT++ Federate&lt;/a&gt; is successfully installed.&lt;/p&gt;
 &lt;h5 id=&#34;prepare-omnet-ide&#34;&gt;Prepare OMNeT++ IDE&lt;/h5&gt;
 &lt;ol&gt;
 &lt;li&gt;
 &lt;p&gt;Create an empty directory somewhere inside your home directory. We will call it &lt;code&gt;&amp;lt;omnetpp_workspace&amp;gt;&lt;/code&gt; from here on. This directory will be used as a workspace in your OMNeT++ IDE.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Open your OMNeT++ IDE by executing &lt;code&gt;omnetpp&lt;/code&gt; in your terminal.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Select &lt;code&gt;&amp;lt;omnetpp_workspace&amp;gt;&lt;/code&gt; as workspace and continue by clicking &lt;code&gt;Launch&lt;/code&gt;.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Close the &amp;ldquo;Welcome&amp;rdquo; screen.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Since your workspace is empty, the OMNeT++ IDE will ask you if you want to install the INET framework and OMNeT++ programming examples.&lt;br&gt;


 &lt;figure id=&#34;figure-omnet-ide-install-inet&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-install-inet.png&#34; data-caption=&#34;OMNeT&amp;#43;&amp;#43; IDE: Install INET&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-install-inet.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OMNeT++ IDE: Install INET
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 Decide by yourself if you want to do that:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;By clicking &lt;code&gt;OK&lt;/code&gt; the INET framework is going to be installed into an &lt;code&gt;inet&lt;/code&gt; folder in your &lt;code&gt;&amp;lt;omnetpp_workspace&amp;gt;&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;If you already have INET installed somewhere you can skip the installation and import your existing INET project:
 &lt;ol&gt;
 &lt;li&gt;&lt;code&gt;Cancel&lt;/code&gt; the dialog.&lt;/li&gt;
 &lt;li&gt;Choose &lt;code&gt;File&lt;/code&gt; &amp;gt; &lt;code&gt;Open Projects from File System...&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;In the new window choose the directory of your existing INET installation as &lt;code&gt;Import Source&lt;/code&gt; and click &lt;code&gt;Finish&lt;/code&gt;&lt;/li&gt;
 &lt;/ol&gt;
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;The project &lt;code&gt;inet&lt;/code&gt; should now be visible in the &lt;code&gt;Project Explorer&lt;/code&gt; of your OMNeT++ IDE.&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Right-click on free space in the &lt;code&gt;Project Explorer&lt;/code&gt; and choose &lt;code&gt;New&lt;/code&gt; &amp;gt; &lt;code&gt;OMNeT++ Project...&lt;/code&gt;&lt;/p&gt;


 &lt;figure id=&#34;figure-omnet-ide-create-new-omnet-project&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-new-project.png&#34; data-caption=&#34;OMNeT&amp;#43;&amp;#43; IDE: Create new OMNeT&amp;#43;&amp;#43; Project&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-new-project.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OMNeT++ IDE: Create new OMNeT++ Project
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;In the new window:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Name the new project &lt;code&gt;federate&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;&lt;strong&gt;Uncheck&lt;/strong&gt; the box before &lt;code&gt;Use default location&lt;/code&gt;, click &lt;code&gt;Browse&lt;/code&gt; and select:&lt;br&gt;
 &lt;code&gt;&amp;lt;mosaic&amp;gt;/bin/fed/omnetpp/omnetpp_federate_src/src&lt;/code&gt;&lt;br&gt;


 &lt;figure id=&#34;figure-omnet-ide-create-new-omnet-project&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-new-project-2.png&#34; data-caption=&#34;OMNeT&amp;#43;&amp;#43; IDE: Create new OMNeT&amp;#43;&amp;#43; Project&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-new-project-2.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OMNeT++ IDE: Create new OMNeT++ Project
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/li&gt;
 &lt;li&gt;Click &lt;code&gt;Next&lt;/code&gt;&lt;/li&gt;
 &lt;/ol&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;On the following &lt;code&gt;Initial Contents&lt;/code&gt; page select &lt;code&gt;Empty Project&lt;/code&gt; and continue by clicking &lt;code&gt;Finish&lt;/code&gt;&lt;br&gt;
 You should now find two projects in the &lt;code&gt;Project Explorer&lt;/code&gt; of your OMNeT++ IDE: &lt;code&gt;inet&lt;/code&gt; and &lt;code&gt;federate&lt;/code&gt;&lt;/p&gt;
 &lt;/li&gt;
 &lt;li&gt;
 &lt;p&gt;Right-click on the &lt;code&gt;federate&lt;/code&gt; project and choose &lt;code&gt;Properties&lt;/code&gt;&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;Go to &lt;code&gt;Project references&lt;/code&gt; and &lt;strong&gt;check&lt;/strong&gt; the box before &lt;code&gt;inet&lt;/code&gt;&lt;br&gt;


 &lt;figure id=&#34;figure-choose-project-references&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-project-references.png&#34; data-caption=&#34;Choose project references&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-project-references.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Choose project references
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;That&amp;rsquo;s it! None of the files should now be marked with an error symbol.&lt;/p&gt;
 &lt;hr&gt;
 &lt;h5 id=&#34;configure-rebuild-configuration&#34;&gt;Configure Rebuild Configuration&lt;/h5&gt;
 &lt;p&gt;Since the Eclipse MOSAIC OMNeT++ Federate is not a classic OMNeT++ project, it cannot be build regulary with
 the OMNeT++ IDE by just clicking on the &lt;code&gt;Build&lt;/code&gt; button. However, to make the build process easy and intuitive
 we provide a simple build script and the following desciption how to configure the OMNeT++ IDE to enable
 building on a single click:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;In the OMNeT++ IDE select &lt;code&gt;Run&lt;/code&gt; &amp;gt; &lt;code&gt;External Tools&lt;/code&gt; &amp;gt; &lt;code&gt;External Tools Configuration...&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Double-click in the left column on &lt;code&gt;Program&lt;/code&gt; to create a new configuration.&lt;/li&gt;
 &lt;li&gt;Call it &lt;code&gt;rebuild federate&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;In the &lt;code&gt;Main&lt;/code&gt; tab:
 &lt;ol&gt;
 &lt;li&gt;Under &lt;code&gt;Location&lt;/code&gt; choose &lt;code&gt;Browse Workspace...&lt;/code&gt; and select &lt;code&gt;federate/rebuild_federate.sh&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Still in the &lt;code&gt;Main&lt;/code&gt; tab under &lt;code&gt;Working Directory&lt;/code&gt; choose &lt;code&gt;Browse Workspace...&lt;/code&gt; and select &lt;code&gt;federate&lt;/code&gt;


 &lt;figure id=&#34;figure-omnet-ide-build-configuration&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-build-config.png&#34; data-caption=&#34;OMNeT&amp;#43;&amp;#43; IDE Build Configuration&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-build-config.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OMNeT++ IDE Build Configuration
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;/li&gt;
 &lt;li&gt;In the &lt;code&gt;Build&lt;/code&gt; tab &lt;strong&gt;uncheck&lt;/strong&gt; the box before &lt;code&gt;Build before launch&lt;/code&gt;&lt;br&gt;


 &lt;figure id=&#34;figure-omnet-ide-build-configuration&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-build-config-2.png&#34; data-caption=&#34;OMNeT&amp;#43;&amp;#43; IDE Build Configuration&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-build-config-2.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     OMNeT++ IDE Build Configuration
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/li&gt;
 &lt;li&gt;Now you can &lt;code&gt;Apply&lt;/code&gt; your changes and click on &lt;code&gt;Run&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;Since you have built the project at least once, you can rebuild it again by clicking here:&lt;br&gt;


 &lt;figure id=&#34;figure-run-rebuild&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-run-rebuild.png&#34; data-caption=&#34;Run rebuild&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-run-rebuild.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Run rebuild
   &lt;/figcaption&gt;


 &lt;/figure&gt;
 &lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;&lt;strong&gt;The following video shows the above described steps:&lt;/strong&gt;&lt;/p&gt;


 &lt;video controls &gt;
   &lt;source src=&#34;../images/omnetpp-ide-rebuild-federate.mp4&#34; type=&#34;video/mp4&#34;&gt;
 &lt;/video&gt;
 &lt;hr&gt;
 &lt;h5 id=&#34;configure-debug-configuration&#34;&gt;Configure Debug Configuration&lt;/h5&gt;
 &lt;p&gt;To debug the Eclipse MOSAIC OMNeT++ Federate during simulation you need to create a Debug Configuration. The following
 instruction will tell you how to that:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;In your OMNeT++ IDE choose &lt;code&gt;Run&lt;/code&gt; &amp;gt; &lt;code&gt;Debug Configurations...&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;In the new window double-click on &lt;code&gt;OMNeT++ Simulation&lt;/code&gt; in the left column and name the new created debug configuration &lt;code&gt;federate&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;In the &lt;code&gt;Executable&lt;/code&gt; row check &lt;code&gt;other&lt;/code&gt; and type &lt;code&gt;/federate/federate&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;In the &lt;code&gt;Working dir&lt;/code&gt; row type &lt;code&gt;/federate&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;In the &lt;code&gt;Ini file(s)&lt;/code&gt; row type &lt;code&gt;debug.ini omnetpp.ini&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;At the end of the page click on the &lt;code&gt;More &amp;gt;&amp;gt;&lt;/code&gt; link. And make sure all fields in the &lt;code&gt;Advanced&lt;/code&gt; area are &lt;strong&gt;empty&lt;/strong&gt;.&lt;/li&gt;
 &lt;li&gt;For &lt;code&gt;Projects to build&lt;/code&gt; select &lt;code&gt;Do not build automatically before launch&lt;/code&gt;&lt;/li&gt;
 &lt;li&gt;Now &lt;code&gt;Apply&lt;/code&gt; your changes and try your configuration by clicking &lt;code&gt;Debug&lt;/code&gt;&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;&lt;strong&gt;The following images shows the final debug configuration:&lt;/strong&gt;&lt;/p&gt;


 &lt;figure id=&#34;figure-final-debug-configuration&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/omnetpp-ide-debug-config.png&#34; data-caption=&#34;Final debug configuration&#34;&gt;


   &lt;img src=&#34;../images/omnetpp-ide-debug-config.png&#34; alt=&#34;&#34;  &gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Final debug configuration
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;hr&gt;
 &lt;h3 id=&#34;the-omnet-ambassador&#34;&gt;The OMNeT++ Ambassador&lt;/h3&gt;
 &lt;p&gt;The OMNeT++ Ambassador is the intermediate component between OMNeT++ and Eclipse MOSAIC. As it
 implements the interface of an abstract federate ambassador in Eclipse MOSAIC. In the initialization phase the
 Ambassador applies for the TimeManagement policies time constrained and time regulated at the RTI.
 Remind that time constrained means that the time advances of the OMNeT++ Federate are dependent on
 the other simulators in the federation and time regulating means that the OMNeT++ Federate itself can
 prevent other federates from advancing their time.&lt;/p&gt;
 &lt;p&gt;The OMNeT++ simulation starts initially with an empty event queue and hence it needs to receive an
 interaction to fill the event queue with the first events to be processed. That means that the typical time
 management cycle in the Ambassador starts at step two with the Receive Interaction procedure. Note
 that messages within Eclipse MOSAIC usually effect more than one interaction e.g. a VehicleUpdates interaction
 contains information for added nodes and moved nodes. These are exchanged with OMNeT++ using a
 simple byte protocol. After this procedure the third step of time management cycle is processed with
 the initial Time Advance Grant. This is the point when the OMNeT++ simulation is able to start and the
 initialization phase is finished. Hence the time management cycle can be executed from first step which
 is waiting for a new NER until no federate requests further events and the simulation is finished.&lt;/p&gt;
 &lt;h3 id=&#34;the-time-representation&#34;&gt;The Time Representation&lt;/h3&gt;
 &lt;p&gt;One important issue for the simulation coupling is the common representation of the logical time at the
 RTI and the different federates in the federation. Normally, the time is a federate-defined abstract data
 type. The requirements for such a time are the ability for comparison and addition and most important
 the possibility of conversion without the loss of precision. Otherwise, deadlocks in the synchronization
 procedure are guaranteed. On the one hand Eclipse MOSAIC treats times as a 64-bit integer with a resolution of
 nanoseconds. On the other hand the OMNeT++ simulation time is represented by the type &lt;code&gt;simtime_t&lt;/code&gt;
 which is a typedef to double. It is generally known that conversions from floating point to fixed point are
 vulnerable to rounding errors. To circumvent this issue the underlying raw 64-bit integer of the &lt;code&gt;simtime_t&lt;/code&gt;
 representation is also made accessible, which works perfect if the scale exponent for time precision was
 previously initialized to $-9$ (i.e. nanoseconds).&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Delay Models</title>
       <link>https://www.eclipse.org/mosaic/docs/extending_mosaic/delay_models/</link>
       <pubDate>Tue, 30 Jun 2020 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/extending_mosaic/delay_models/</guid>
       <description>&lt;p&gt;MOSAIC has different types of delays implemented for different use cases. This page will
 give a short introduction into the types and their usages, as well as example configurations,
 which are used throughout MOSAIC. The implementations can be
 found in the package &lt;code&gt;org.eclipse.mosaic.lib.model.delay&lt;/code&gt;.
 Note prior to the release of MOSAIC delay values were configured using Milliseconds as unit,
 this has been refactored to Nanoseconds. Alternatively you can specify delay values using
 a String with a unit (eg &lt;code&gt;&amp;quot;delay&amp;quot;: &amp;quot;20 ms&amp;quot;&lt;/code&gt;).&lt;/p&gt;
 &lt;h2 id=&#34;delay-models&#34;&gt;Delay Models&lt;/h2&gt;
 &lt;p&gt;The &lt;code&gt;Delay&lt;/code&gt; class represents an implementation for a specific delay model. The following model implementation exist:&lt;/p&gt;
 &lt;h3 id=&#34;constantdelay&#34;&gt;ConstantDelay&lt;/h3&gt;
 &lt;p&gt;The &lt;code&gt;ConstantDelay&lt;/code&gt;-class is arguably the simplest implementation of &lt;code&gt;Delay&lt;/code&gt;. This model is configured with a single
 field &lt;code&gt;delay&lt;/code&gt;, which the &lt;code&gt;generateDelay(...)&lt;/code&gt;-method will simply return.&lt;br&gt;
 While this delay doesn&amp;rsquo;t provide realistic behaviour in most cases it is optimal for testing purposes as it
 can easily be retraced.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Configuration:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;delay&amp;quot;: {
     &amp;quot;type&amp;quot;: &amp;quot;ConstantDelay&amp;quot;,
     &amp;quot;delay&amp;quot;: &amp;quot;20 ms&amp;quot;
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;simplerandomdelay&#34;&gt;SimpleRandomDelay&lt;/h3&gt;
 &lt;p&gt;The &lt;code&gt;SimpleRandomDelay&lt;/code&gt; model allows for the generated delays to be randomly distributed between a &lt;code&gt;minDelay&lt;/code&gt; and a &lt;code&gt;maxDelay&lt;/code&gt;.
 Additionally, the &lt;code&gt;steps&lt;/code&gt; field is used to limit the amount of different delays, by equally separating the interval into
 the amount of steps specified. This delay provides a simple and performant way to randomize and thereby more realistically reflect real-world delays.&lt;/p&gt;
 &lt;p&gt;For example, with the configuration below, one of the following delays is randomly chosen: &lt;code&gt;[0.4, 0.9, 1.4, 1.9, 2.4] ms&lt;/code&gt;.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Configuration:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;delay&amp;quot;: {
     &amp;quot;type&amp;quot;: &amp;quot;SimpleRandomDelay&amp;quot;,
     &amp;quot;steps&amp;quot;: 5,
     &amp;quot;minDelay&amp;quot;: &amp;quot;0.4 ms&amp;quot;,
     &amp;quot;maxDelay&amp;quot;: &amp;quot;2.4 ms&amp;quot;
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;gamma-delays&#34;&gt;Gamma Delays&lt;/h3&gt;
 &lt;p&gt;MOSAIC provides two types of delays using a Gamma-distribution to sample values, namely &lt;code&gt;GammaRandomDelay&lt;/code&gt; and &lt;code&gt;GammaSpeedDelay&lt;/code&gt;.
 The parameters for the used Gamma-distribution have been determined experimentally. The &lt;code&gt;GammaSpeedDelay&lt;/code&gt; extends the &lt;code&gt;GammaRandomDelay&lt;/code&gt;
 by a speed penalty. Both delay-types aim to provide more realistic solution, than the previous models, but come with the downside of complexity.&lt;/p&gt;
 &lt;p&gt;&lt;strong&gt;Configurations:&lt;/strong&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;delay&amp;quot;: {
     &amp;quot;type&amp;quot;: &amp;quot;GammaRandomDelay&amp;quot;,
     &amp;quot;minDelay&amp;quot;: &amp;quot;10 ms&amp;quot;,
     &amp;quot;expDelay&amp;quot;: &amp;quot;30 ms&amp;quot;
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;delay&amp;quot;: {
     &amp;quot;type&amp;quot;: &amp;quot;GammaSpeedDelay&amp;quot;,
     &amp;quot;minDelay&amp;quot;: &amp;quot;10 ms&amp;quot;,
     &amp;quot;expDelay&amp;quot;: &amp;quot;30 ms&amp;quot;
 }
 &lt;/code&gt;&lt;/pre&gt;
 </description>
     </item>

     <item>
       <title>Network Simulator Cell</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_cell/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/network_simulator_cell/</guid>
       <description>&lt;p&gt;The built-in Eclipse MOSAIC Cell Simulator enables the applications to use cellular network communication.
 The simulation of cellular communication in Eclipse MOSAIC consists of two parts:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;The Cellular Simulator itself and&lt;/li&gt;
 &lt;li&gt;The applications that can communicate over cellular networks in the Application Simulator&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;These changes are done in a generic way, making the cellular simulator exchangeable. Users interested
 in a different kind of simulation of cellular communication may use other simulators and develop
 ambassadors connecting them to Eclipse MOSAIC.&lt;/p&gt;
 &lt;p&gt;The Cellular Simulator in the current state consists of three main modules:&lt;/p&gt;
 &lt;ol&gt;
 &lt;li&gt;UplinkModule&lt;/li&gt;
 &lt;li&gt;GeocasterModule&lt;/li&gt;
 &lt;li&gt;DownlinkModule&lt;/li&gt;
 &lt;/ol&gt;
 &lt;p&gt;The Geocaster module simulates a mandatory component for ITS communication. It is inspired by
 the several architectures from research projects as simTD or CONVERGE to enable ITS use cases over
 cellular networks. It mainly takes over the task of an addressing and routing component with geographic
 knowledge to support geo-addressing. However, it also supports regular topological addressing.
 The Uplink and DownlinkModule are responsible for the transmission simulation. They account for the
 aspects of transmission delays, packet losses and available data rates. In this context,Uplink and Downlink
 always refer to the direction towards respectively from the Geocaster. For instance, a transmission
 from an Internet-based server towards a vehicle would include an Uplink between the server and the
 Geocaster and a Downlink between the Geocaster and the vehicle. While the Uplink direction only allows
 point-to-point communication (Unicast), the Downlink supports point-to-point (Unicast) as well as
 point-to-multipoint (Multicast).&lt;/p&gt;
 &lt;h3 id=&#34;cellambassador-folder-structure&#34;&gt;CellAmbassador folder structure&lt;/h3&gt;
 &lt;p&gt;The Eclipse MOSAIC Cell simulator can be configured via three distinct configuration files, which can be
 found within the scenarios&#39; folder structure:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ cell
       ├─ cell_config.json ................ Cell ambassador configuration file
       ├─ network.json ..................... Network configuration file
       └─ regions.json ..................... Regions configuration file
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The network and regions configuration files are referenced in the cellular ambassador configuration
 file.&lt;/p&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC-installation package.&lt;/p&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;We provide a cellular configuration file in the example scenarios of Tiergarten and Barnim. Please note
 that in the default configuration of this scenario the Cellular Simulator is deactivated. To activate the
 cellular simulator just enable the &lt;code&gt;cell&lt;/code&gt; federate in the &lt;code&gt;scenario_config.json&lt;/code&gt;:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: {
     ...
     &amp;quot;cell&amp;quot;: true,
     ...
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The central configuration for the cellular simulator in the file
 &lt;code&gt;&amp;lt;scenarioName&amp;gt;/cell/cell_config.json&lt;/code&gt; could look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-Json&#34;&gt;{
     &amp;quot;debugGeocasting&amp;quot;: false,
     &amp;quot;visualizeRegions&amp;quot;: true,
     &amp;quot;networkConfigurationFile&amp;quot;: &amp;quot;network.json &amp;quot;,
     &amp;quot;regionConfigurationFile&amp;quot;: &amp;quot;regions.json &amp;quot;
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The &lt;code&gt;visualizeRegions-option&lt;/code&gt; from the &lt;code&gt;cell_config.json&lt;/code&gt; is used to write a KML-file that visualizes the
 used cell regions. Google Earth can be used to display it.&lt;/p&gt;
 &lt;p&gt;The configuration for the global network in the cellular simulator in the file
 &lt;code&gt;&amp;lt;scenarioName&amp;gt;/cell/network.json&lt;/code&gt; could look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;globalNetwork&amp;quot;: {
         &amp;quot;uplink&amp;quot;: {
             &amp;quot;delay&amp;quot;: {
                 &amp;quot;type&amp;quot;: &amp;quot;ConstantDelay&amp;quot;,
                 &amp;quot;delay&amp;quot;: &amp;quot;100 ms&amp;quot;
             },
             &amp;quot;transmission&amp;quot;: {
                 &amp;quot;lossProbability&amp;quot;: 0.0,
                 &amp;quot;maxRetries&amp;quot;: 2
             },
             &amp;quot;capacity&amp;quot;: 28000000
         },
         &amp;quot;downlink&amp;quot;: {
             &amp;quot;unicast&amp;quot;: {
                 &amp;quot;delay&amp;quot;: {
                     &amp;quot;type&amp;quot;: &amp;quot;ConstantDelay&amp;quot;,
                     &amp;quot;delay&amp;quot;: &amp;quot;50 ms&amp;quot;
                 },
                 &amp;quot;transmission&amp;quot;: {
                     &amp;quot;lossProbability&amp;quot;: 0.0,
                     &amp;quot;maxRetries&amp;quot;: 2
                 }
             },
             &amp;quot;multicast&amp;quot;: {
                 &amp;quot;delay&amp;quot;: {
                     &amp;quot;type&amp;quot;: &amp;quot;ConstantDelay&amp;quot;,
                     &amp;quot;delay&amp;quot;: &amp;quot;100 ms&amp;quot;
                 },
                 &amp;quot;transmission&amp;quot;: {
                     &amp;quot;lossProbability&amp;quot;: 0.0
                 },
                 &amp;quot;usableCapacity&amp;quot;: 0.6
             },
             &amp;quot;capacity&amp;quot;: 42200000
         }
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;The &lt;code&gt;network.json&lt;/code&gt; also allows setting the fields &lt;code&gt;defaultDownlinkCapacity&lt;/code&gt; and &lt;code&gt;defaultUplinkCapacity&lt;/code&gt;,
 which are used if you don&amp;rsquo;t specify any bitrates in your &lt;code&gt;CellConfiguration&lt;/code&gt;s inside your applications.
 These values are set to 100 Gigabit by default, so if you aren&amp;rsquo;t interested in capacity/bandwidth observations you can
 probably just leave them as is.&lt;/p&gt;
 &lt;h3 id=&#34;server-configuration&#34;&gt;Server configuration&lt;/h3&gt;
 &lt;p&gt;MOSAIC supports a type of simulation units, called servers. Traffic Management Centers are a specialised type of server.
 What differentiates servers from other units is, that
 they are treated as having no geographical location and instead are located &amp;ldquo;inside the internet.&amp;rdquo;. This concept omits prior shortcoming,
 where one would have to configure RSU&amp;rsquo;s as servers.&lt;br&gt;
 Servers are also configured in the &lt;code&gt;network.json&lt;/code&gt; as follows:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;defaultDownlinkCapacity&amp;quot;: &amp;quot;10 Gbps&amp;quot;,
     &amp;quot;defaultUplinkCapacity&amp;quot;: &amp;quot;10 Gbps&amp;quot;,
     &amp;quot;globalNetwork&amp;quot;: {
            [...]
     },
     &amp;quot;servers&amp;quot;: {
         {
             &amp;quot;id&amp;quot;: &amp;quot;TestServer&amp;quot;,
             &amp;quot;uplink&amp;quot;: {
                 &amp;quot;delay&amp;quot;: {
                     &amp;quot;type&amp;quot;: &amp;quot;ConstantDelay&amp;quot;,
                     &amp;quot;delay&amp;quot;: &amp;quot;200 ms&amp;quot;
                 },
                 &amp;quot;transmission&amp;quot;: {
                     &amp;quot;lossProbability&amp;quot;: 0.5,
                     &amp;quot;maxRetries&amp;quot;: 2
                 }
             },
             &amp;quot;downlink&amp;quot;: {
                 &amp;quot;unicast&amp;quot;: {
                     &amp;quot;delay&amp;quot;: {
                         &amp;quot;type&amp;quot;: &amp;quot;SimpleRandomDelay&amp;quot;,
                         &amp;quot;steps&amp;quot;: 5,
                         &amp;quot;minDelay&amp;quot;: &amp;quot;100 ms&amp;quot;,
                         &amp;quot;maxDelay&amp;quot;: &amp;quot;200 ms&amp;quot;
                     },
                     &amp;quot;transmission&amp;quot;: {
                         &amp;quot;lossProbability&amp;quot;: 0.1,
                         &amp;quot;maxRetries&amp;quot;: 2
                     }
                 }
             }
         },
         {
             [...]
         }
     }
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;blockquote&gt;
 &lt;p&gt;Note: The fields &lt;code&gt;defaultDownlinkCapacity&lt;/code&gt;, &lt;code&gt;defaultUplinkCapacity&lt;/code&gt; are used if you don&amp;rsquo;t define any bitrates for your cell configurations
 their default values are 100 Gigabit, so you usually don&amp;rsquo;t need to set them.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;p&gt;Servers get their configuration for the delay and retransmission models from the &lt;code&gt;network.json&lt;/code&gt; and the configuration for the
 capacity-model has to be made from within an application, by activating the &lt;code&gt;CellModule&lt;/code&gt; and properly setting the bit rates.
 This could look as follows:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;        getOs().getCellModule().enable(
                 new CellModuleConfiguration()
                         .maxUlBitrate(10000)
                         .maxDlBitrate(10000)
         );

         // Alternatively using default values from network.json
         getOs().getCellModule().enable();
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;For the CellAmbassador to be able to recognize servers, the &lt;code&gt;group&lt;/code&gt;-field in the mapping must match the &lt;code&gt;id&lt;/code&gt;-field in the &lt;code&gt;network.json&lt;/code&gt;,
 this also allows for multiple servers to utilize the same configuration. A &lt;code&gt;mapping_config.json&lt;/code&gt; using the configuration from
 above could look as follows:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     ...,
     &amp;quot;tmcs&amp;quot;: [
         {
             &amp;quot;group&amp;quot;: &amp;quot;TestServer&amp;quot;,
             &amp;quot;applications&amp;quot;: [ &amp;quot;TestApplication&amp;quot; ],
             &amp;quot;inductionLoops&amp;quot;: [ ],
             &amp;quot;laneAreaDetectors&amp;quot;: [ ]
         }
     ],
     &amp;quot;servers&amp;quot;: [
         {
             &amp;quot;group&amp;quot;: &amp;quot;TestServer&amp;quot;,
             &amp;quot;applications&amp;quot;: [ &amp;quot;TestApplication&amp;quot; ]
         }
     ],
     ...
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;blockquote&gt;
 &lt;p&gt;Note that all bandwidths are given in bit per second and all delays in nanoseconds, unless explicitly defined differently.
 Also, every json configuration goes through a minifier, so comments are allowed in the configuration files. An example
 would be the comment before the &lt;code&gt;globalNetwork&lt;/code&gt; option.&lt;/p&gt;
 &lt;/blockquote&gt;
 &lt;h3 id=&#34;delay-regions&#34;&gt;Delay regions&lt;/h3&gt;
 &lt;p&gt;Additionally, the user has the option to define regions with individual delays. This can be used to simulate
 areas with bad reception, crowded areas etc.&lt;/p&gt;
 &lt;p&gt;The regions should be stored in &lt;code&gt;&amp;lt;scenarioName&amp;gt;/cell/regions.json&lt;/code&gt;. An
 example definition for a single region called &lt;code&gt;Ernst-Reuter-Platz&lt;/code&gt; could look like this:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-Json&#34;&gt;{
     &amp;quot;regions&amp;quot;:[
         {
             &amp;quot;id&amp;quot;: &amp;quot;Ernst-Reuter-Platz&amp;quot;,
             &amp;quot;area&amp;quot;: {
                 &amp;quot;nw&amp;quot;: { &amp;quot;lon&amp;quot;:13.3249, &amp;quot;lat&amp;quot;:52.5131 },
                 &amp;quot;se&amp;quot;: { &amp;quot;lon&amp;quot;:13.3273, &amp;quot;lat&amp;quot;:52.5125 }
             },
             &amp;quot;uplink&amp;quot;: {
                 &amp;quot;delay&amp;quot;: {
                     &amp;quot;type&amp;quot;:         &amp;quot;SimpleRandomDelay&amp;quot;,
                     &amp;quot;steps&amp;quot;:        4,
                     &amp;quot;minDelay&amp;quot;:     &amp;quot;50 ms&amp;quot;,
                     &amp;quot;maxDelay&amp;quot;:     &amp;quot;200 ms&amp;quot;
                 },
                  &amp;quot;transmission&amp;quot;: {
                      &amp;quot;lossProbability&amp;quot;: 0.8,
                      &amp;quot;maxRetries&amp;quot;: 2
                 },
                 &amp;quot;capacity&amp;quot;:         28000000
             },
             &amp;quot;downlink&amp;quot;: {
                 &amp;quot;unicast&amp;quot;: {
                     &amp;quot;delay&amp;quot;: {
                         &amp;quot;type&amp;quot;:         &amp;quot;SimpleRandomDelay&amp;quot;,
                         &amp;quot;steps&amp;quot;:        3,
                         &amp;quot;minDelay&amp;quot;:     &amp;quot;100 ms&amp;quot;,
                         &amp;quot;maxDelay&amp;quot;:     &amp;quot;200 ms&amp;quot;
                     },
                     &amp;quot;transmission&amp;quot;: {
                         &amp;quot;maxRetries&amp;quot;: 2
                     }
                 },
                 &amp;quot;multicast&amp;quot;: {
                     &amp;quot;delay&amp;quot;: {
                         &amp;quot;type&amp;quot;:         &amp;quot;SimpleRandomDelay&amp;quot;,
                         &amp;quot;steps&amp;quot;:        3,
                         &amp;quot;minDelay&amp;quot;:     &amp;quot;120 ms&amp;quot;,
                         &amp;quot;maxDelay&amp;quot;:     &amp;quot;220 ms&amp;quot;
                     },
                     &amp;quot;transmission&amp;quot;: {
                         &amp;quot;lossProbability&amp;quot;: 0.8
                     },
                     &amp;quot;usableCapacity&amp;quot;:   0.6
                 },
                 &amp;quot;capacity&amp;quot;:             42200000
             }
         }
     ]
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;Note that &lt;code&gt;nw&lt;/code&gt; represents the upper-left (north-west) point of the rectangle and &lt;code&gt;se&lt;/code&gt; the lower-right (southeast).
 For further information about the possible options, please refer to the Eclipse MOSAIC API documentation.&lt;/p&gt;
 &lt;p&gt;The actual configuration of the uplink and the downlink modules for each region exhibits the identical
 format as configuration of the globalNetwork in the &lt;code&gt;network.json&lt;/code&gt;.&lt;/p&gt;
 &lt;p&gt;When no regions are found, or if a node (a vehicle) is not within a specified region, the globalNetwork
 defined in the &lt;code&gt;network.json&lt;/code&gt;-File will be used as the delay model.&lt;/p&gt;
 &lt;h3 id=&#34;transmission-simulation&#34;&gt;Transmission simulation&lt;/h3&gt;
 &lt;p&gt;One of the most important feature of the cellular simulator is an estimation of the delay experienced
 through the transport over the cellular network.&lt;/p&gt;
 &lt;p&gt;The cellular simulator offers various modes to estimate the delay of the transmissions. The type of
 estimation is specified with by &lt;code&gt;delayType&lt;/code&gt; for the uplink and downlink for each region. You may also refer to the

 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/extending_mosaic/delay_models/&#34;&gt;Delay-Chapter&lt;/a&gt;.&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;code&gt;delay.type = ’ConstantDelay’&lt;/code&gt;: The message is transmitted with the latency being exactly equal to delay.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;delay.type = ’SimpleRandomDelay’&lt;/code&gt;: The latency can assume different (randomly generated and uniformly distributed) values between
 &lt;code&gt;minDelay&lt;/code&gt; and &lt;code&gt;maxDelay&lt;/code&gt;. The number of different values is determined by &lt;code&gt;steps&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;delay.type = ’GammaRandomDelay’&lt;/code&gt;: A gamma distribution is used to estimate the latency, with $ \alpha $ = 2 and  $ \beta $= 2. The
 minimal delay &lt;code&gt;minDelay&lt;/code&gt; is added to the result. The curve is fitted so that the maximum likelihood for the delay is exactly equal to
 &lt;code&gt;expDelay&lt;/code&gt;.&lt;/li&gt;
 &lt;li&gt;&lt;code&gt;delay.type = ’GammaSpeedDelay’&lt;/code&gt;: This mode closely resembles the GammaRandomDelay. Additionally, a penalty for the velocity with which
 the node is moving is calculated. This penalty is then added to the original delay. The GammaRandomDelay and the GammaSpeedDelay are
 derived from a measurement campaign during a research project at the DCAITI.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;The two different modes for the downlink are &lt;code&gt;unicast&lt;/code&gt; and &lt;code&gt;multicast&lt;/code&gt; which are configured separately. Multicast aims to simulate the
 features of Multimedia Broadcast Multicast Service (MBMS). The main difference in terms of the transmission for unicast and multicast
 is the handling of undeliverable messages. For unicast, the options &lt;code&gt;lossProbability&lt;/code&gt; and &lt;code&gt;maxRetries&lt;/code&gt; are used. Pr is short for
 packet retransmit and denotes the probability for a failed delivery and a subsequent retransmit. The maximum number of retries
 for the retransmission is configured through the &lt;code&gt;maxRetries&lt;/code&gt;-option. The probability of a successful
 retransmit is recalculated on every try.&lt;/p&gt;
 &lt;p&gt;In case of multicast the &lt;code&gt;lossProbability&lt;/code&gt; is used as packet loss rate. The value is factored into the delay calculation.
 In contrast to the unicast, just one transmission attempt is made for multicast.&lt;/p&gt;
 &lt;h3 id=&#34;operation&#34;&gt;Operation&lt;/h3&gt;
 &lt;p&gt;Beside the transmission simulation, the Addressing and Routing is the other important aspect of the Cellular Simulator. This task is enabled
 by the Geocaster.&lt;/p&gt;
 &lt;p&gt;The Geocaster evaluates the message headers for cellular messages, which are created by the communicating applications in the
 Application Simulator.&lt;/p&gt;
 &lt;p&gt;It supports the following addressing and casting schemes.&lt;/p&gt;
 &lt;p&gt;
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/communication/#cellular-topocast&#34;&gt;&lt;strong&gt;&lt;code&gt;CellTopocast&lt;/code&gt;&lt;/strong&gt;&lt;/a&gt; is the normal unicast, where the Geocaster simply resolves
 the single receiver via theIPResolver. Hence, the CellTopocast directly routes the message further. Currently, Topocast doesn&amp;rsquo;t allow
 broadcast or anycast addresses, but any transmission protocols (tcp, udp).&lt;/p&gt;
 &lt;p&gt;
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/communication/#cellular-geocast&#34;&gt;&lt;strong&gt;&lt;code&gt;CellGeoUnicast&lt;/code&gt;&lt;/strong&gt;&lt;/a&gt; addresses every node in the destination area individually.
 In this way it takes a geographic address and results in a loop to generate multiple unicasts.&lt;/p&gt;
 &lt;p&gt;
 &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/develop_applications/communication/#cellular-geobroadcast&#34;&gt;&lt;strong&gt;&lt;code&gt;CellGeoBroadcast&lt;/code&gt;&lt;/strong&gt;&lt;/a&gt;, which is basically MBMS, uses one broadcast to all
 nodes in the destined regions.The MBMS uses the different transmission mode of multicast in the downlink. CellGeoUnicast as well as
 CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied).&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Environment Simulator</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/environment_simulator/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/environment_simulator/</guid>
       <description>&lt;p&gt;This ambassador can be configured with a configuration file. The specific path is &lt;code&gt;mosaic/scenarios/&amp;lt;scenarioName&amp;gt;/environment/environment_config.json&lt;/code&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ environment
       └─ environment.json ................. Environment ambassador configuration file
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC-installation package.&lt;/p&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;The root node of the configuration is a list of environment events. Each event require the type of the event, a rectangle area, a
 strength and the time window. The following example shows the configuration of an &amp;ldquo;Obstacle&amp;rdquo; event which is valid in the
 designated area (Rectangle) during the simulation time between 0 to 2000 seconds:&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
     &amp;quot;events&amp;quot; : [
         {
             &amp;quot;type&amp;quot;: {
                 &amp;quot;sensorType&amp;quot;: &amp;quot;OBSTACLE&amp;quot;,
                 &amp;quot;value&amp;quot;: 1
             },
             &amp;quot;location&amp;quot;: {
                 &amp;quot;area&amp;quot;: {
                     &amp;quot;type&amp;quot;: &amp;quot;Rectangle&amp;quot;,
                     &amp;quot;a&amp;quot;: {
                         &amp;quot;latitude&amp;quot;: 52.53654,
                         &amp;quot;longitude&amp;quot;: 13.42116
                     },
                     &amp;quot;b&amp;quot;: {
                         &amp;quot;latitude&amp;quot;: 52.53435,
                         &amp;quot;longitude&amp;quot;: 13.42366
                     }
                 }
             },
             &amp;quot;time&amp;quot;: {
                 &amp;quot;start&amp;quot;: &amp;quot;0 s&amp;quot;,
                 &amp;quot;end&amp;quot;: &amp;quot;2000 s&amp;quot;
             }
         }
     ]
 }
 &lt;/code&gt;&lt;/pre&gt;
 </description>
     </item>

     <item>
       <title>Battery Simulator</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/battery_simulator/</link>
       <pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/battery_simulator/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
 &lt;p&gt;The &lt;strong&gt;Battery Simulator&lt;/strong&gt; is part of &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;.&lt;br&gt;
 For further information on licenses, feel free to contact us via &lt;strong&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;mosaic@fokus.fraunhofer.de&lt;/a&gt;&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;The MOSAIC Battery Simulator is used to simulate electric vehicles. It takes environment, vehicle
 characteristics and the battery itself into account. The main feature of the battery ambassador is that it
 can utilize dynamic class loading to use a battery model provided by the user, depending on the given
 needs. This also holds true for the environment model and the vehicle model. However, simple models
 for vehicle, environment and the battery are provided and will be briefly explained in the following
 sections.&lt;/p&gt;
 &lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
 &lt;p&gt;This simulator does not need to be installed. It is delivered as part of the MOSAIC Extended installation package.&lt;/p&gt;
 &lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
 &lt;p&gt;This ambassador can be configured with a configuration file. The specific path is
 &lt;code&gt;&amp;lt;scenarioName&amp;gt;/battery/battery_config.json&lt;/code&gt;&lt;/p&gt;
 &lt;pre&gt;&lt;code class=&#34;language-FOLDER&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
    └─ battery
       └─ battery_config.json ................. Battery ambassador configuration file
 &lt;/code&gt;&lt;/pre&gt;
 &lt;h3 id=&#34;vehicle-model&#34;&gt;Vehicle model&lt;/h3&gt;
 &lt;p&gt;The vehicle model holds the general properties of a vehicle. Examples would be the weight of the vehicle
 and the voltage at which the electric engine operates. However, as with the other models, the provided
 class for the vehicle model direct affects what can be configured here. If other properties are needed for
 the vehicle, this is the right place to put them. To implement an own vehicle, the class AVehicleModel
 has to be extended.&lt;/p&gt;
 &lt;h3 id=&#34;battery-model&#34;&gt;Battery model&lt;/h3&gt;
 &lt;p&gt;The battery model defines the battery used by the vehicle itself. Useful properties could be the number
 of cells and their capacity. As with the vehicle, this class can be freely defined and use configuration
 values placed in the &lt;code&gt;batteryModelConfig-area&lt;/code&gt;. To implement an own battery model, the class &lt;code&gt;ABatteryModel&lt;/code&gt;
 needs to be extended.&lt;/p&gt;
 &lt;h3 id=&#34;environment-model&#34;&gt;Environment model&lt;/h3&gt;
 &lt;p&gt;Normally environmental factors like rolling resistance of the given underground or air drag go into this
 section. At the current state, just a minimal environment model is bundled with the battery ambassador,
 mainly to show what is possible. To implement a custom environmentmodel, &lt;code&gt;AEnvironmentModel&lt;/code&gt; has
 to be extended.&lt;/p&gt;
 &lt;h3 id=&#34;sample-configuration&#34;&gt;Sample configuration&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-Json&#34;&gt;{
     &amp;quot;vehicleModelClass&amp;quot;: &amp;quot;com.dcaiti.mosaic.fed.battery.sim.models.vehicle.ElectricSmart&amp;quot;,
     &amp;quot;vehicleModelConfig&amp;quot;: {
             &amp;quot;Mass&amp;quot;: 1060,
             &amp;quot;ReferenceArea&amp;quot;: 1.95,
             &amp;quot;DragCoefficient&amp;quot;: 0.375,
             &amp;quot;TankToWheelEfficiency&amp;quot;: 0.7,
             &amp;quot;EletricMotorOperatingVoltage&amp;quot;: 350,
             &amp;quot;ConsumerOperatingVoltage&amp;quot;: 12
     },
     &amp;quot;batteryModelClass&amp;quot;: &amp;quot;com.dcaiti.mosaic.fed.battery.sim.models.battery.VerySimpleBatteryModel&amp;quot;,
     &amp;quot;batteryModelConfig&amp;quot;: {
             &amp;quot;NumberOfCells&amp;quot;: 93,
             &amp;quot;CellVoltage&amp;quot;: 4.3,
             &amp;quot;CellCapacityInAh&amp;quot;: 50,
             &amp;quot;eff_Summer&amp;quot;: 0.8448,
             &amp;quot;RechargingType&amp;quot;: 2,
             &amp;quot;MinSOC&amp;quot;: 0.30,
             &amp;quot;MaxSOC&amp;quot;: 0.70
         },
     &amp;quot;environmentModelClass&amp;quot;: &amp;quot;com.dcaiti.mosaic.fed.battery.sim.models.environment.DefaultEnvironment&amp;quot;,
     &amp;quot;environmentModelConfig&amp;quot;: {
             &amp;quot;Gravity&amp;quot;: 9.81,
             &amp;quot;FluidDensity&amp;quot;: 1.293,
             &amp;quot;RollingResistanceCoefficient&amp;quot;: 0.01
         },
         &amp;quot;consumers&amp;quot;: [ { &amp;quot;Radio&amp;quot;: 10 }, { &amp;quot;HeadLight&amp;quot;: 100 } ]
 }
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;This listing shows how the vehicle, environment and battery model classes for the bundled models are configured. Additionally, an arbitrary number of consumers can be configured that draw additional power from the battery. In this case, headlights and a radio are pre-defined.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Variable Message Signs Simulator</title>
       <link>https://www.eclipse.org/mosaic/docs/simulators/vms_simulator/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/docs/simulators/vms_simulator/</guid>
       <description>&lt;div class=&#34;alert alert-extended&#34;&gt;
   &lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
   &lt;div&gt;
 &lt;p&gt;The &lt;strong&gt;VMS Simulator&lt;/strong&gt; is part of &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/download#overview&#34; title=&#34;MOSAIC Extended&#34;&gt;MOSAIC Extended&lt;/a&gt;&lt;/strong&gt;.&lt;br&gt;
 For further information on licenses, feel free to contact us via &lt;strong&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;&lt;a href=&#34;mailto:mosaic@fokus.fraunhofer.de&#34;&gt;mosaic@fokus.fraunhofer.de&lt;/a&gt;&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;
   &lt;/div&gt;
 &lt;/div&gt;
 &lt;p&gt;The VMS Simulator extends simulations with variable message signs (VMS), which could by dynamically controlled. A VMS can be placed anywhere along a road and
 has, amongst others, the following properties:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;&lt;em&gt;Type&lt;/em&gt; for different traffic sign semantics,&lt;/li&gt;
 &lt;li&gt;&lt;em&gt;Road and lane(s)&lt;/em&gt; it corresponds to,&lt;/li&gt;
 &lt;li&gt;&lt;em&gt;Visibility&lt;/em&gt; as a value telling how well a sign is visible for road users&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;The concept of a flexible sign type allows testing future traffic signs which are not existent at the moment and also common VMS types like:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Speed limit signs&lt;/li&gt;
 &lt;li&gt;Lane assignment signs (assigns a list of allowed vehicle types to a lane - e.g. Busses, Taxis or even Automated Vehicles)&lt;/li&gt;
 &lt;/ul&gt;


 &lt;figure id=&#34;figure-example-of-speed-and-lane-assigment-in-highway-scenario&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;../images/vms-simulator_signs-highway.png&#34; data-caption=&#34;example of speed and lane assigment in highway scenario&#34;&gt;


   &lt;img src=&#34;../images/vms-simulator_signs-highway.png&#34; alt=&#34;&#34; width=&#34;85%&#34; &gt;
 &lt;/a&gt;


   &lt;figcaption&gt;
     example of speed and lane assigment in highway scenario
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;Any properties of a VMS, beside its position and type, can be changed during the simulation.&lt;/p&gt;
 &lt;p&gt;In each simulation step the VMS Simulator informs vehicles about any VMS that is inside their sight distance. How
 vehicles react on VMS can be modeled with the &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/&#34; title=&#34;Application Simulator&#34;&gt;Application Simulator&lt;/a&gt;.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Studying Traffic Control Algorithms in MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/post/traffic-control/</link>
       <pubDate>Mon, 18 Jan 2021 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/post/traffic-control/</guid>
       <description>&lt;p&gt;&lt;strong&gt;The simulative investigation of communication-based Traffic Management solutions requires combining models from different domains. Eclipse MOSAIC suits very well for this purpose as it couples multiple simulators to model vehicle movement pattern, infrastructure sensors, (variable) traffic signs, as well as different communication links (ITS-G5, 4G/5G) between vehicles and backends, and the application logic in entities like vehicles and a Traffic Management Center.&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;&lt;img src=&#34;featured.png&#34; alt=&#34;alternative text for search engines&#34;&gt;&lt;/p&gt;
 &lt;p&gt;In a recent, study we analyzed future traffic estimation and control algorithms towards their use on highways
 with special focus on mixed traffic of conventional vehicles, connected vehicles, and autonomous vehicles. Connected
 vehicles share telematic information with a Traffic Management Center (TMC) which can then estimate the traffic state
 and initiate control mechanisms to improve traffic efficiency either via variable message signs as part of the infrastructure, or via V2X communication directly addressing connected vehicles in order to share
 speed and lane change advices with the vehicles on the road (e.g. via ETSI IVI message). In a further step,
 dynamic lane assignments have been established, which dedicate lanes to autonomous vehicles only to enable
 efficient platooning maneuvers. The individual highlights of Eclipse MOSAIC for simulating such a traffic management system are visualized in the video.&lt;/p&gt;
 &lt;video controls style=&#34;width:55%&#34;&gt;
   &lt;source src=&#34;https://owncloud.fokus.fraunhofer.de/index.php/s/LclLTzGQ0BdziIn/download&#34; type=&#34;video/mp4&#34;&gt;
 &lt;/video&gt;
 &lt;p&gt;With &lt;strong&gt;Eclipse MOSAIC&lt;/strong&gt; this system has been modelled and simulated with all its various aspects in order to analyze
 efficiency improvements of such estimation and control algorithms. As traffic simulator, we employed
 &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/traffic_simulator_sumo/&#34; title=&#34;Eclipse SUMO&#34;&gt;Eclipse SUMO&lt;/a&gt;&lt;/strong&gt;, which already provides a basic
 model for variable &lt;em&gt;speed&lt;/em&gt; signs. However, the preferred &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/vms_simulator/&#34; title=&#34;MOSAIC VMS Simulator&#34;&gt;MOSAIC VMS Simulator&lt;/a&gt;
 realizes a more flexible concept with the dynamic control of the VMS during simulation runtime, including &lt;em&gt;arbitrary sign semantics&lt;/em&gt; additional
 to &lt;em&gt;speed&lt;/em&gt; and featuring a visibility range. The interplay of information from infrastructure elements as well as communicated information
 has been modelled in detail with applications covering realistic behavior of human drivers and autonomous vehicles. Additionally,
 real estimation and control algorithms from external suppliers have been integrated into the simulation to
 provide a software-in-the-loop environment. The &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/#eclipse-mosaic-mapping&#34; title=&#34;MOSAIC Mapping&#34;&gt;MOSAIC Mapping&lt;/a&gt;&lt;/strong&gt;
 allowed for a comprehensive configuration of the different application components to the simulated entities (variously equipped vehicles, RSUs and a TMC cloud server).&lt;/p&gt;
 &lt;p&gt;The final result was a complex simulation scenario for Eclipse MOSAIC,
 including a calibrated traffic model, various application and behavior models for automated, connected and conventional vehicles,
 different communication links via ITS-G5 and cellular communication, infrastructure models for sensors and variable message signs, and
 a new evaluation component in order to gain statistics out of a simulation.&lt;/p&gt;
 &lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th style=&#34;text-align:left&#34;&gt;Requirement&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/traffic_simulator_sumo/&#34; title=&#34;SUMO&#34;&gt;SUMO&lt;/a&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/&#34; title=&#34;MOSAIC Application&#34;&gt;MOSAIC Application&lt;/a&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_cell/&#34; title=&#34;MOSAIC Cell&#34;&gt;MOSAIC Cell&lt;/a&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_sns/&#34; title=&#34;MOSAIC SNS&#34;&gt;MOSAIC SNS&lt;/a&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/vms_simulator/&#34; title=&#34;MOSAIC VMS&#34;&gt;MOSAIC VMS&lt;/a&gt;&lt;/th&gt;
 &lt;th style=&#34;text-align:center&#34;&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/visualization/statistics/&#34; title=&#34;MOSAIC Output&#34;&gt;MOSAIC Output&lt;/a&gt;&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Simulate Vehicle Traffic on Highways&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Measure Traffic Properties (Flow, Density)&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Control Traffic dynamically via VMS&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;(X)&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Exchange V2X Messages via ITS-G5 and 4G/5G&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Include Vehicle Functions which react on IVIM&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Model Traffic Management Center Facilities&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Integrate real TMC algorithms in Simulation&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Include Roadside Units with custom Functionality&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Generate aggregated Statistics from the Simulation&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td style=&#34;text-align:left&#34;&gt;Generated Detailed Simulation Logs&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;(X)&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;&lt;/td&gt;
 &lt;td style=&#34;text-align:center&#34;&gt;X&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
 &lt;/table&gt;
 &lt;h3 id=&#34;the-simulation-setup&#34;&gt;The Simulation Setup&lt;/h3&gt;
 &lt;p&gt;The traffic model in this scenario has been created using real toll-data for the highway AP7 in northern Spain, provided
 by the Spanish toll road management (
 &lt;a href=&#34;https://www.abertis.com&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Abertis Infraestructuras, S.A.&lt;/a&gt;). Based on this data, traffic has been
 generated in Eclipse SUMO and calibrated in a way,
 that the simulated traffic resembles the original toll data as close as possible. This procedure has been done for the
 complete highway AP7 and resulted in more than 500.000 vehicles per day in the simulation. However, it would not make real sense
 to analyze a whole highway stretch, as the control algorithms under test apply very local changes. Therefore, we decided to extract
 a reduced traffic scenario from the calibrated one by measuring the vehicle movements within a smaller area only. Based on those
 measurements we were able to create a realistic traffic model on a stretch of 25 kilometers length near Girona.&lt;/p&gt;


 &lt;figure id=&#34;figure-the-test-site-modelled-in-eclipse-mosaic&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/test-site_huc9e68466259c66b25b58dd1cb0735621_545645_2000x2000_fit_lanczos_2.png&#34; data-caption=&#34;The test site modelled in Eclipse MOSAIC&#34;&gt;


   &lt;img data-src=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/test-site_huc9e68466259c66b25b58dd1cb0735621_545645_2000x2000_fit_lanczos_2.png&#34; class=&#34;lazyload&#34; alt=&#34;&#34; width=&#34;45%&#34; height=&#34;551&#34;&gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     The test site modelled in Eclipse MOSAIC
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;For modelling the infrastructure, the highway has been divided into so-called segments. Each segment, roughly 500m in length, contains
 spot sensors at the entry of each segment to measure traffic flow, lane area detectors which model cameras to measure traffic density, and
 Variable Message Signs (VMS) displaying speed limits and lane assignments. Modelling VMS was achieved by the new
 simulator &lt;strong&gt;MOSAIC VMS&lt;/strong&gt;, which let vehicles &amp;ldquo;see&amp;rdquo; oncoming traffic signs showing speed limits or lane assignments. An additional
 behavior model for vehicles implemented in the MOSAIC Application Simulator could react on those instructions accordingly.&lt;/p&gt;
 &lt;p&gt;The segmentation of the highway was very important for the traffic estimation and control algorithms which have been integrated into the scenario. Those
 algorithms, provided by the
 &lt;a href=&#34;https://www.pem.tuc.gr/index.php?id=5257&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Technical University of Crete&lt;/a&gt;, can
 estimate the traffic volume on highways using traditional sensors, but also by receiving CAM messages of connected vehicles. Based on the
 traffic estimation, additional algorithms can control the traffic by setting speed limits on VMS, or by sending V2X messages (e.g. ETSI IVI messages)
 with speed recommendations or lane change advices to individual vehicles. The control algorithms were written in C++ and have already been used in real
 traffic management centers. For this study, we integrated them into the &lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/&#34; title=&#34;MOSAIC Application&#34;&gt;MOSAIC Application&lt;/a&gt;
 Simulator using the Java Native Interface (JNI).&lt;/p&gt;


 &lt;figure id=&#34;figure-integration-of-traffic-control-algorithms-into-mosaic-application-using-jni&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-jni_hu8eedbfac73273995571fbc96a05c851b_31297_2000x2000_fit_lanczos_2.png&#34; data-caption=&#34;Integration of Traffic Control Algorithms into MOSAIC Application using JNI&#34;&gt;


   &lt;img data-src=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-jni_hu8eedbfac73273995571fbc96a05c851b_31297_2000x2000_fit_lanczos_2.png&#34; class=&#34;lazyload&#34; alt=&#34;&#34; width=&#34;45%&#34; height=&#34;632&#34;&gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Integration of Traffic Control Algorithms into MOSAIC Application using JNI
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;The estimation algorithms rely on information from vehicles and control algorithms are able to send back advices. Therefore, communication
 links are required to exchange V2X messages. To achieve this, two separate communications links have been modelled by integrating
 the &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_sns/&#34; title=&#34;MOSAIC Simple Network Simulator&#34;&gt;MOSAIC Simple Network Simulator&lt;/a&gt;&lt;/strong&gt; for ITS-G5 communication,
 and the  &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_cell/&#34; title=&#34;MOSAIC Cell Simulator&#34;&gt;MOSAIC Cell Simulator&lt;/a&gt;&lt;/strong&gt; for cellular communication (e.g. 5G or LTE-V2X).
 In the former case, vehicles exchanged message with Road Side Units along the road, which then forwarded the information to the Traffic Management
 Center (TMC). In the latter case, vehicles were directly connected to the TMC.&lt;/p&gt;
 &lt;p&gt;Finally, application models for connected and automated vehicles have been integrated by using the
 &lt;strong&gt;&lt;a href=&#34;https://www.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/&#34; title=&#34;MOSAIC Application Simulator&#34;&gt;MOSAIC Application Simulator&lt;/a&gt;&lt;/strong&gt;. With the help of these applications
 vehicles could react on advices sent by the TMC. Depending on the SAE level of the vehicle in the simulation, the vehicles
 would execute a certain advice immediately after some safety checks (fully automated vehicle) or with a certain delay
 (connected vehicle with a human driver reacting on a lane-change advice).&lt;/p&gt;
 &lt;h3 id=&#34;evaluations&#34;&gt;Evaluations&lt;/h3&gt;
 &lt;p&gt;In a first study, we took a closer look onto the main traffic flow control (MTFC) in general. This algorithm measures the traffic volume
 on the highway and adjusts the speed limits shown on VMS based on the current flow and density. In many cases, traffic collapses
 near on-ramps when traffic flow on the highway is already high and additional vehicles are entering, resulting in a capacity drop
 on the highway and thereby congestion further upstream. To avoid this from happening, the controller reduces the average speed
 of the main flow resulting in more capacity available at the bottleneck. This effect could be shown in MOSAIC with the setup described
 above as well, as shown in the Figure below. Here you can see, that the congestion which arises at the bottleneck near segment 30 can
 be reduced by activating the controller.&lt;/p&gt;


 &lt;figure id=&#34;figure-speed-over-time-on-the-highway-left-no-control-enabled-right-control-algorithm-active&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-no-control-vs-control_hu3f36ae42f5012c9c73c42f4df7e25b4b_269788_2000x2000_fit_lanczos_2.png&#34; data-caption=&#34;Speed over time on the highway. Left no control enabled, right control algorithm active.&#34;&gt;


   &lt;img data-src=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-no-control-vs-control_hu3f36ae42f5012c9c73c42f4df7e25b4b_269788_2000x2000_fit_lanczos_2.png&#34; class=&#34;lazyload&#34; alt=&#34;&#34; width=&#34;70%&#34; height=&#34;400&#34;&gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     Speed over time on the highway. Left no control enabled, right control algorithm active.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;In the previous case, the controller adjusted the speed limit shown on VMS along the highway. Those VMS were placed virtually every
 500m along the highway, which would be very expensive to implement on real highways. Therefore, we reduced the number of
 VMS placed along the highway and tested the algorithm again. VMS were now placed at strategic positions rather than equidistant. To be more
 precisely, five VMS were placed between two consecutive on-ramps, having one VMS to control the speed near the bottleneck, three safety VMS which reduce
 the speed stepwise further upstream, and one VMS after the on-ramp to release the vehicles from the control area. As a result, we
 could spare over 60% of the VMS placed along the specific highway stretch without seeing much difference in the results.&lt;/p&gt;


 &lt;figure id=&#34;figure-in-the-left-case-vms-are-placed-every-500m-in-the-right-case-only-few-vms-at-strategic-locations&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-full-vms-vs-few-vms_hu3f36ae42f5012c9c73c42f4df7e25b4b_266372_2000x2000_fit_lanczos_2.png&#34; data-caption=&#34;In the left case, VMS are placed every 500m. In the right case only few VMS at strategic locations.&#34;&gt;


   &lt;img data-src=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-full-vms-vs-few-vms_hu3f36ae42f5012c9c73c42f4df7e25b4b_266372_2000x2000_fit_lanczos_2.png&#34; class=&#34;lazyload&#34; alt=&#34;&#34; width=&#34;70%&#34; height=&#34;400&#34;&gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     In the left case, VMS are placed every 500m. In the right case only few VMS at strategic locations.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;p&gt;In addition to controlling the traffic by setting VMS, vehicles do receive speed limits or speed advices via communication using IVI messages.
 Those messages contain control decisions for each segment and are spread to the vehicles using ITS-G5 adhoc communication. For this purpose,
 the simulation scenario is modelled in a way, that a road side unit is placed at each segment entry. Equipped vehicles adjust their speeds and
 therefore control the traffic flow as a whole, as other vehicles (e.g. their followers) are forced to adjust their speeds as well. With this fact
 given, we did another experiment in which we eliminated all VMS completely and sent speed limits only via V2X communication to
 equipped vehicles. This, on one hand, already works with rather low penetration rates of 15 percent equipped vehicles, as shown in the Figure
 below. Furthermore, the higher the penetration rate is, the better the controller works. For high penetration rates, this technique even surpasses the classic
 approach via VMS slightly, as connected vehicles can react and controlled more precisely.&lt;/p&gt;


 &lt;figure id=&#34;figure-in-the-left-case-traffic-is-controlled-via-vms-in-the-right-case-only-v2x-messages-are-utilized&#34;&gt;


   &lt;a data-fancybox=&#34;&#34; href=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-full-vms-vs-ivim_hu3f36ae42f5012c9c73c42f4df7e25b4b_269336_2000x2000_fit_lanczos_2.png&#34; data-caption=&#34;In the left case traffic is controlled via VMS. In the right case, only V2X messages are utilized.&#34;&gt;


   &lt;img data-src=&#34;https://www.eclipse.org/mosaic/mosaic/post/traffic-control/teac-full-vms-vs-ivim_hu3f36ae42f5012c9c73c42f4df7e25b4b_269336_2000x2000_fit_lanczos_2.png&#34; class=&#34;lazyload&#34; alt=&#34;&#34; width=&#34;70%&#34; height=&#34;400&#34;&gt;
 &lt;/a&gt;


   &lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
     In the left case traffic is controlled via VMS. In the right case, only V2X messages are utilized.
   &lt;/figcaption&gt;


 &lt;/figure&gt;

 &lt;h3 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h3&gt;
 &lt;p&gt;We modelled complex traffic scenarios including road infrastructures (sensors, dynamic traffic signs, road side units), individual driving
 behavior for different SAE levels. Furthermore, we integrated real algorithms for traffic estimation and control into MOSAIC Application
 enabling software-in-the-loop tests. By creating and calibrating a highway scenario using real toll data, we could test different
 traffic control techniques which showed that traffic flow on highways could be improved, even with novel approaches which do not
 rely on classic infrastructure such as road sensors and Variable Message Signs, but almost solely on V2X communication.&lt;/p&gt;
 &lt;hr&gt;
 &lt;p&gt;
 &lt;a href=&#34;https://www.inframix.eu/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;&lt;img src=&#34;inframix.png&#34; alt=&#34;INFRAMIX EU&#34;&gt;&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;This work was part of the
 &lt;a href=&#34;https://www.inframix.eu&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;INFRAMIX&lt;/a&gt; project. INFRAMIX has received funding from
 the European Union&amp;rsquo;s Horizon 2020 research and innovation programme under grant
 agreement no 723016.&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>First release of Eclipse MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/post/release-20-0/</link>
       <pubDate>Mon, 19 Oct 2020 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/post/release-20-0/</guid>
       <description>&lt;p&gt;&lt;strong&gt;The initial contribution is accomplished! With the autumn version, the committer team from Fraunhofer FOKUS and DCAITI is proud to release Eclipse MOSAIC 20.0 to the open source community. With the runtime infrastructure, core libraries and various implementations of simulators or couplings to existing ones, Eclipse MOSAIC includes the essential feature collection for simulation and virtual testing of connected and automated mobility solutions.&lt;/strong&gt;&lt;/p&gt;
 &lt;h3 id=&#34;release-date&#34;&gt;Release Date&lt;/h3&gt;
 &lt;p&gt;2020-10-19&lt;/p&gt;
 &lt;h3 id=&#34;changelog&#34;&gt;Changelog&lt;/h3&gt;
 &lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;[M+] Moved main code to new public repository github-com/eclipse-mosaic
 [M+] Changed license to EPL 2.0
 [M+] Revised and refactored all public code.
 [M+] Significantly improved and extended the documentation, including new tutorials
 [M-] Replaced dependencies which are incompatible with EPL.
 [M+] Major overhaul of configuration files, e.g.
      * vsimrti/vsimrti_config.xml -&amp;gt; scenario_config.json
      * etc/defaults.xml -&amp;gt; etc/runtime.json
 [A+] Mapping configuration has been extended with new features (e.g. typeDistributions, parameter variations).
 [A+] New API for traffic light applications
 [C+] SNS supports most important Geo-Routing features for ad-hoc multihop communication
 [T+] Now supports SUMO 1.7.0
 &lt;/code&gt;&lt;/pre&gt;
 &lt;p&gt;&lt;strong&gt;Changelog (Features and Bugfixes) Legend:&lt;/strong&gt;&lt;br&gt;
 &lt;code&gt;[M]&lt;/code&gt; Eclipse MOSAIC&lt;br&gt;
 &lt;code&gt;[A]&lt;/code&gt; Application simulator&lt;br&gt;
 &lt;code&gt;[B]&lt;/code&gt; Battery simulator&lt;br&gt;
 &lt;code&gt;[C]&lt;/code&gt; Communication simulator&lt;br&gt;
 &lt;code&gt;[E]&lt;/code&gt; Environment simulator&lt;br&gt;
 &lt;code&gt;[N]&lt;/code&gt; Navigation component&lt;br&gt;
 &lt;code&gt;[S]&lt;/code&gt; Scenario-convert&lt;br&gt;
 &lt;code&gt;[T]&lt;/code&gt; Traffic simulator&lt;br&gt;
 &lt;code&gt;[+/-]&lt;/code&gt; new Feature/Bugfix&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>Testing mobility scenarios with the Open-Source simulation environment Eclipse MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/post/eclipse-mosaic/</link>
       <pubDate>Fri, 16 Oct 2020 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/post/eclipse-mosaic/</guid>
       <description>&lt;p&gt;&lt;strong&gt;On the occasion of EclipseCon 2020, Fraunhofer FOKUS launches its simulation environment Eclipse MOSAIC. This solution is based on VSimRTI (Vehicle-2-X Simulation Runtime Infrastructure), which has been developed over the last 12 years in close cooperation with the DCAITI of the TU Berlin and has already been used by more than 600 partners to test mobility services and traffic scenarios. Eclipse MOSAIC is now partially available as open-source.&lt;/strong&gt;&lt;/p&gt;
 &lt;p&gt;Whether dynamic lane assignment or traffic light phase assistant, new mobility services are designed to increase safety, efficiency, comfort, and facilitate environmentally friendly transport. The Eclipse MOSAIC simulation environment allows to explore how this can be achieved, before the services are tested in field trials on the road. Eclipse MOSAIC can also be used for testing driver assistance systems and to optimize the entire traffic.&lt;/p&gt;
 &lt;h2 id=&#34;flexible-coupling-of-simulators&#34;&gt;Flexible coupling of simulators&lt;/h2&gt;
 &lt;p&gt;Eclipse MOSAIC integrates, depending on the simulation scenario, different aspects like individual building blocks into a holistic system, e.g., traffic congestion, battery charging of electric cars, or communication between other road users and a central cloud. The level of detail for individual aspects is variable: from a rough mobility scenario for an entire city to detailed individual driving maneuvers.&lt;/p&gt;
 &lt;p&gt;The open-source version of Eclipse MOSAIC already includes several simulators, e.g., Eclipse SUMO for traffic and OMNeT++ and ns-3 for communication. Further simulators can be coupled, e.g., Fraunhofer FOKUS offers the simulator PHABMACS for the realistic modeling of autonomous vehicles.&lt;/p&gt;
 &lt;p&gt;In addition to the simulator coupling, Eclipse MOSAIC manages the following tasks:&lt;/p&gt;
 &lt;ul&gt;
 &lt;li&gt;Federation: Individual simulators are interchangeable within a scenario.&lt;/li&gt;
 &lt;li&gt;Interaction: Information from one simulator is also taken into account by others.&lt;/li&gt;
 &lt;li&gt;Time: All simulators run synchronously.&lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;Additionally, Eclipse MOSAIC offers several tools for evaluation and visualization of the results, which are also included in the open-source package.&lt;/p&gt;
 &lt;p&gt;In the recently completed EU project INFRAMIX, Eclipse MOSAIC was used to test scenarios for the future road that allow mixed traffic between conventional and automated vehicles.&lt;/p&gt;
 &lt;p&gt;Fraunhofer FOKUS has been a strategic development member of the Eclipse Foundation since May of this year and works in close cooperation with the partners of the working groups OpenMobility and openADx (Open Source for Autonomous Driving).&lt;/p&gt;
 &lt;p&gt;Further information about Eclipse MOSAIC:
 &lt;a href=&#34;https://www.eclipse.org/mosaic&#34;&gt;https://www.eclipse.org/mosaic&lt;/a&gt;
 &lt;a href=&#34;https://github.com/eclipse/mosaic&#34;&gt;https://github.com/eclipse/mosaic&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;Further information about INFRAMIX:
 &lt;a href=&#34;https://www.fokus.fraunhofer.de/de/fokus/news/inframix-projekt_2020_08&#34;&gt;https://www.fokus.fraunhofer.de/de/fokus/news/inframix-projekt_2020_08&lt;/a&gt;&lt;/p&gt;
 &lt;p&gt;Further information about EclipseCon:
 &lt;a href=&#34;https://www.eclipsecon.org/2020&#34;&gt;https://www.eclipsecon.org/2020&lt;/a&gt;&lt;/p&gt;
 </description>
     </item>

     <item>
       <title>About</title>
       <link>https://www.eclipse.org/mosaic/about/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/about/</guid>
       <description></description>
     </item>

     <item>
       <title>Contact</title>
       <link>https://www.eclipse.org/mosaic/get_in_contact/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/get_in_contact/</guid>
       <description></description>
     </item>

     <item>
       <title>Contribution to Eclipse MOSAIC</title>
       <link>https://www.eclipse.org/mosaic/contribution/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/contribution/</guid>
       <description></description>
     </item>

     <item>
       <title>Download</title>
       <link>https://www.eclipse.org/mosaic/download/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/download/</guid>
       <description></description>
     </item>

     <item>
       <title>Eclipse MOSAIC Community</title>
       <link>https://www.eclipse.org/mosaic/community/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/community/</guid>
       <description></description>
     </item>

     <item>
       <title>News</title>
       <link>https://www.eclipse.org/mosaic/news/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/news/</guid>
       <description></description>
     </item>

     <item>
       <title>Publications</title>
       <link>https://www.eclipse.org/mosaic/publications/</link>
       <pubDate>Tue, 01 Jan 2019 00:00:00 +0000</pubDate>
       <guid>https://www.eclipse.org/mosaic/publications/</guid>
       <description></description>
     </item>

   </channel>
 </rss>