Figure 3.11: The Federation Object Model of the co-simulation platform.
3.5 Extensions to Communication Network Simulators
In order to integrate a communication network simulator into the proposed architecture, an existing simulation software package needs to be changed or extended in three areas. The first pertains to the synchronisation of time advancements with external programs while the second area deals with implementing the communication with an HLA-based RTI. Unlike for the MAS integration, the third area is specific to network simulators and must solve the issue of how to represent agent applications within the simulator that can create data traffic during runtime.
3.5.1 Synchronisation and RTI Communication
The most well-known network simulators are already discrete-event systems and there- fore can be integrated into the co-simulation without any changes to the way their models are executed. Nevertheless, they are standalone tools and mostly lack the same two abilities that have been discussed for MAS frameworks. The first absent ability is to synchronise their time advancements with other external programs. The second is the missing ability to communicate with an RTI to make use of the provided simulation services such as the data exchange with other federates.
All network simulators consist of at least two kind of components, a scheduler and net- work objects (see Figure 3.12). The main task of the scheduler is to advance simulation time to the next event on its chronologically-sorted event list and then to execute it. The execution of an event mostly consists of executing the code of the network objects. This execution frequently results in scheduling future events with the scheduler. Network objects are all objects of a network model such as, node models, network stack models,
Figure 3.12: The most basic components of a communication network simulator.
and link models. Figure 3.13 shows the basic flowchart followed by all discrete-event network simulators.
Figure 3.13: The basic flowchart of any discrete-event network simulator.
In order to synchronise time advancements and communicate with the RTI, a network simulator can be extended as shown in Figure 3.14. The new HLA Interface component provides an interface to the runtime infrastructure (RTI) in a similar way the RTI Agent does for the MAS. It calls standardised methods of the RTIAmbassador object to send information to the RTI and receives callbacks via the FederateAbassador object.
Internally, it interacts with the event scheduler and network objects. The scheduler must be modified to request simulation-time advancements through the HLA Interface and wait for the request to be granted before it can advance and execute the next events.
3.5. EXTENSIONS TO COMMUNICATION NETWORK SIMULATORS
Figure 3.14: The extended network simulator.
This approach synchronises the simulator with the overall co-simulation.
Another function of the HLA Interface is to relay interactions that are either received by the RTI or the network objects that represent the agent application within the net- work simulator. When the MAS sends an interaction, which indicates the need for an agent message to be simulated, the HLA Interface receives it via the RTI and forwards the information to the appropriate network object. For this purpose, it uses the infor- mation of the source address field (see Figure 3.11), which holds the node ID where the application resides. On the other hand, an agent application can also send an interac- tion via the HLA Interface and RTI to notify the MAS when an agent message has been received.
Figure 3.15 shows the flowchart of an extended network simulator, which can synchro- nise time advancements with the overall co-simulation and communicate with an RTI. Compared to the basic flowchart (see Figure 3.13), it has an additional state where it waits until time advance requests have been granted by the RTI. Similarly to the pre- viously described RTI Agent, the network simulator communicates with the RTI during the initialisation, simulation, and at the simulation end. During the initialisation the HLA Interface takes care of the initial setup such as, joining the federation, setting time management parameters, publishing, and subscribing to interactions that hold agent
message information. It also registers to the same synchronisation point as the MAS and then waits until the RTI instructs all federates that it is safe to advance. During the main simulation loop the RTI is contacted to request time advancements. The last communication with the RTI happens at the end of the simulation when the simulator resigns from the federation.
Figure 3.15: The flowchart of an extended network simulator.
The suggested changes to an existing network simulator are only possible if the source code is available or it features APIs that allow to control the scheduler. Open source sim- ulators are the easiest to extend because the behaviour of the scheduler can be changed and the HLA Interface added. Alternatively, closed source software packages must ex- pose the necessary APIs so that the proposed functionality can be implemented. Chapter 4.5 shows how to adapt a well established commercial network simulator.
3.5.2 Generic Agent Application
Another issue that needs to be addressed is how to represent the agent application within a network simulator. In general, an application implements a particular logic and gener- ates data traffic to be simulated. Most simulation packages already come with popular client/server applications based on internet technologies, such as File Transport Proto- col (FTP), Hypertext Transfer Protocol (HTTP), database queries, and voice/video over
3.5. EXTENSIONS TO COMMUNICATION NETWORK SIMULATORS
IP. Also, they usually provide a framework to create new client/server applications that are not readily available. The provided or newly created applications define prior to the start of the simulation when and what kind of data traffic is simulated. For example, a database client application model would define when database queries are sent to the server, how much data is sent, and which transport protocol to use. Even though some of these properties can be based on random numbers and different probability distri- butions, it is not possible to influence them after the simulation has started. This is perfectly acceptable for self-contained network simulations but for the purpose of the co-simulation platform, applications are needed that can generate all sorts of traffic (e.g. different packet sizes, destinations, and transport protocols) during runtime. Interac- tions sent by the MAS to the network simulator must be able to inject new data traffic even after the co-simulation has started.
Figure 3.16: The generic agent model as part of the node model.
A generic agent application model that can represent any application within the net- work simulator is proposed to address the previously stated issues. It is part of node models, as shown in Figure 3.16, and sits on top of the transport layer, which means that it can take advantage of already modeled internet technologies, such as TCP/IP,
UDP, ICMP, WiFi, or Ethernet. It is generic in the sense that there is only one model for all possible agent applications regardless of their function. In essence, it acts as a generator as well as a sink of data traffic. When it receives an interaction from the MAS via the HLA Interface, it creates data traffic based on the received payload size, destination address, and message ID that comes with the interaction (see Figure 3.11). On the other hand, when a generic agent receives data, it sends a similar interaction back to the MAS via the HLA Interface. The interaction contains the same message ID as the interaction that initiated the creation of the received data. This information enables the MAS to establish which agent message has been received.
The suggested generic agent application gives the MAS the means to create new data traffic within the network simulator during runtime. The interactions that are exchanged between the federates serve as a system to exchange agent message information. This generic approach enables the network modeller to use the exact same agent application model to represent any agent running in the MAS. This means that the network mod- eller does not need to be aware of the agent logic and the MAS and network model development is separated from each other.