Template for ping applications. It shows what gates a ping app needs, to be able to be used in StandardHost etc.

Not an actual module type. It only shows which gates an SCTP app should have to be able to be used in StandardHost etc.

Template for TCP applications. It shows what gates a TCP app needs, to be able to be used in StandardHost etc.

Not an actual module type. It only shows which gates a TUN app should have to be able to be used in StandardHost

Template for UDP applications. It shows what gates a UDP app needs, to be able to be used in StandardHost etc.

Implements the DHCP client protocol. DHCP (Dynamic Host Configuration Protocol), described in RFC 2131, provides configuration parameters to Internet hosts. Requires UDP.

Implements the DHCP server protocol. DHCP (Dynamic Host Configuration Protocol), described in RFC 2131, provides configuration parameters to Internet hosts. Requires UDP.

A simple traffic generator for the Ethernet model and the 802.11 model, and generally for any L2 model that accepts Ieee80211Ctrl control info on the packets. It generates EtherAppReq packets. It should be connected directly to EtherLLC or a Ieee802NicXXX module.

Server side of the EtherCli model -- generates EtherAppResp packets with the number of bytes requested by the client in EtherAppReq. It should be connected directly to EtherLLC or a Ieee802NicXXX module.

****************************************************** @file EthernetApplication.cc @brief Simple traffic generator. It generates Etherapp requests and responses. Based in EtherAppCli and EtherAppSrv.

A simple traffic generator for the Ethernet model and the 802.11 model, and generally for any L2 model that accepts Ieee80211Ctrl control info on the packets. It should be connected directly to EtherEncap or an Ieee802NicXXX module.

Prototype for modules that generate traffic directly over IP. Compatible with both IPv4 and IPv6.

Sends IP or IPv6 datagrams to the given address at the given sendInterval. The sendInterval can be a constant or a random value (e.g. exponential(1)). If the destAddresses parameter contains more than one address, one of them is randomly for each packet. An address may be given in the dotted decimal notation (or, for IPv6, in the usual notation with colons), or with the module name. (The L3AddressResolver class is used to resolve the address.) To disable the model, set destAddresses to "".

Consumes and prints packets received from the IP module. Compatible with both IPv4 and IPv6.

The component is derived from HttpBrowseBase and is intended to be used with the INET frameworks StandardHost and TCP/IP stack modeling.

This component is the direct message passing version of the browser simulation component. It is derived from HttpBrowserBase. Use this component with the DirectHost container module.

Interface for HTTP server and browser models that communicate directly, without lower layer protocols. This module is intended for use with the DirectHost module and plugs in as a tcpApp.

A controller object for OMNeT++ simulations which use the HttpTools browser and server components. A single controller must exist at the scenario level in each simulation.

A Web server module for OMNeT++ simulations. This module is intended for use with the INET StandardHost module and plugs in as a tcpApp. The INET TCP/IP stack modeling is used for transport. See the INET documentation for more details.

A Web server module for OMNeT++ simulations and direct message passing between modules. This module is intended for use with the DirectHost module and plugs in as a tcpApp.

Demonstrates subclassing the server to create a custom site. This site is an attacker -- a puppetmaster -- which serves HTML pages containing attack code. In this case, we are simulating JavaScript attack code which prompts the unsuspecting browser to request a number of images from a victim site. Delays are specified to simulate hiding the attack from the browser user by use of JavaScript timeouts or similar mechanisms. The generateBody virtual function is redefined to create a page containing the attack code.

Demonstrates subclassing the server to create a custom site. This site is an attacker -- a puppetmaster -- which serves HTML pages containing attack code. In this case, we are simulating JavaScript attack code which prompts the unsuspecting browser to issue a number of requests for non-existing resources (random URLS) to the victim site. Delays are specified to simulate hiding the attack from the browser user by use of JavaScript timeouts or similar mechanisms. The generateBody virtual function is redefined to create a page containing the attack code.

Demonstrates subclassing the server to create a custom site. This site is an attacker -- a puppetmaster -- which serves HTML pages containing attack code. In this case, we are simulating JavaScript attack code which prompts the unsuspecting browser to request a number of images from a victim site. Delays are specified to simulate hiding the attack from the browser user by use of JavaScript timeouts or similar mechanisms. The generateBody virtual function is redefined to create a page containing the attack code.

HttpServerEvilB

Application model for comparing the performance of various transport protocols.

NetPerfMeter application host.

To disable send, specify empty destAddr.

The RTPApplication is just a very simple sample for an application which uses RTP. It acts as a sender if the parameter fileName is set, and as a receiver if the parameter is empty.

Client app for SCTP-based request-reply protocols. Handles a single session (and SCTP connection) at a time.

Client for a generic request-response style protocol over TCP. May be used as a rough model of HTTP or FTP users. Compatible with both IPv4 (IPv4) and IPv6.

Accepts any number of incoming TCP connections, and sends back the messages that arrive on them, The lengths of the messages are multiplied by echoFactor before sending them back (echoFactor=1 will result in sending back the same message unmodified.) The reply can also be delayed by a constant time (echoDelay parameter).

Generic server application for modelling TCP-based request-reply style protocols or applications.

Single-connection TCP application: it opens a connection, sends the given number of bytes, and closes. Sending may be one-off, or may be controlled by a "script" which is a series of (time, number of bytes) pairs. May act either as client or as server, and works with TCPVirtualBytesSendQueue/RcvQueue as sendQueue/receiveQueue setting for TCP. Compatible with both IPv4 (IPv4) and IPv6.

Accepts any number of incoming TCP connections, and discards whatever arrives on them. Compatible with both IPv4 and IPv6.

This module hosts TCP-based server applications. It dynamically creates and launches a new "thread" object for each incoming connection.

Models Telnet sessions with a specific user behaviour. The server app should be TCPGenericSrvApp. Compatible with both IPv4 and IPv6.

Sends UDP packets to the given IP address at the given interval. Compatible with both IPv4 and IPv6.

Sends UDP packets to the given IP address(es) in bursts, or acts as a packet sink. Compatible with both IPv4 and IPv6.

Listens on an UDP port, and sends back each received packet to its sender. Note: when used together with UDPBasicApp, UDPBasicApp's "received packet lifetime" statistic will record round-trip times.

Consumes and prints packets received from the UDP module.

Video streaming client.

Video stream server. To be used with UDPVideoStreamCli.

Receives a VoIP stream generated by a SimpleVoIPSender, and records statistics. The most important statistic is MOS (Mean Opinion Score, a value between 1 and 5, representing a human user's view of the voice quality), computed using the E Model defined in the ITU-T G.107 standard. The parameters starting with "emodel_" correspond to the parameters of the E model.

Implements a simple VoIP source. It is a constant bitrate source, with talkspurt support added. Packets do not contain actual voice data. Connection setup/teardown is not modelled. The peer must be a SimpleVoIPReceiver.

VoIPStreamReceiver listens on an UDP port, and expects to receive VoIP packets on it. The received voice is then saved into a result audio file that can be compared with the original for further evaluation. VoIP packets are numbered, and out-of-order packets are discarded (the corresponding voice interval will be recorded as silence into the file). VoIP packets that miss their deadlines will similarly be discarded. It is assumed that the audio is played back with delay (by default 20ms), which allows some jitter for the incoming packets. The resulting audio file is closed when the simulation completes (i.e. in the OMNeT++ finish() function). Only one voice session ("call") may be underway at a time.

VoIPStreamSender accepts an audio file and a destination IP address/port as input, and will transmit the file's contents as voice traffic over UDP n times (by default once). For transmission, the audio is resampled at the specified frequency and depth, and encoded with the specified codec at the specified bit rate, and chopped into packets that each carry specified number of milliseconds of voice. Those values come from module parameters. Packets that are all silence (all samples are below a given threshold in absolute value) are transmitted as special "silence" packets. The module does not simulate any particular VoIP protocol (e.g. RTP), but instead accepts a "header size" parameter that can be set accordingly.

Generic module that can be inserted in some points in the model

Module base for different layered protocols.

Implements @delegatesignal properties. @delegatesignal arranges a source signal to be emitted as a target signal, possibly on another module.

This module interface is used by geogrpahic coordinate systems. A geographic coordinate system maps playground coordinates to geographic coordinates, and vice versa.

This module provides an accurate geographic coordinate system using the built-in OSG API.

This module provides a very simple and less accurate geographic coordinate system without using OSG. It doesn't support orientation

Manages operations like shutdown/restart, suspend/resume, crash/recover and similar operations for nodes (routers, hosts, etc), interfaces, and protocols.

Keeps track of the status of network node (up, down, etc.) for other modules, and also displays it as a small overlay icon on this module and on the module of the network node.

Module that allows checking fields of messages

Records a NetAnim trace, using network-level modules and their connections. See http://www.nsnam.org/wiki/index.php/NetAnim

Emits double-valued signals in the specified interval. May be used for testing indicator figures.

Thruput measurement utility module.

This channels adds suport for thruput meternig to the datarate channel A cDatarateChannel extended with throughput calculation. Values get displayed on the link, using the connection's "t=" display string tag.

Records PCAP traces of frames sent/received by other modules within the same host. By default, it records frames sent/received by L2 modules of StandardHost and Router. The output filename is expected in the pcapFile parameter. The PcapRecorder module can also print tcpdump-like textual information to on the log (EV); this functionality can be controlled by the verbose parameter.

Provides tcpdump-like functionality: dumps packet contents on the module output, and optionally records them into a PCAP file. This module has to be placed into the packet's path, and connected both sides.

Delayer module.

Drop-tail queue, to be used in network interfaces. Conforms to the IOutputQueue interface.

This module implements a passive FIFO queue with unlimited buffer space. It can be combined with algorithmic droppers and schedulers to form an IOutputQueue compound module.

Prototype for output queues. Concrete queues can implement drop-tail, RED etc. policy.

Joins multiple input streams into a single output stream.

Just lets messages through without any change or delay.

Ordinal Based Dropper module.

Ordinal Based Duplicator module.

This module implements a strict priority scheduler.

This module implements Random Early Detection (RED).

Silently discards all received packets.

This module selectively drops packets, based on the available buffer space of the queues attached to its output.

This module implements weighted round-robin scheduling.

ScenarioManager is for setting up and controlling simulation experiments. You can schedule certain events to take place at specified times, like changing a parameter value, changing the bit error rate of a connection, removing or adding connections, removing or adding routes in a routing table, etc, so that you can observe the transient behaviour.

The propagation of communication signals, the movement of communicating agents, or battery exhaustion depend on the surrounding physical environment. For example, signals can be absorbed by objects, can pass through objects, can be refracted by surfaces, can be reflected from surfaces, etc.

An object cache is a data structure that is used by the physical environment to store physical objects.

This object cache model organizes closely positioned physical objects into a tree data structure.

This object cache model stores physical objects in a spatial grid. Each cell maintains a list of intersecting physical objects. The grid is aligned with the coordinate axes and it has a configurable cell size in all dimensions. The cell size parameters take precedence over the cell count parameters.

Module base for different MAC protocols.

Implementation of B-MAC (called also Berkeley MAC, Low Power Listening or LPL). See C++ documentation for details.

An example QoS classifier that assigns a User Priority based on the transport protocol and port numbers.

Interface for 802.1d QoS classifiers. For each packet, the classifier computes a 802.1d User Priority (UP) value, and sets in on the Iee802Ctrl control info before sending out the packet on the "out" gate.

A QoS classifier that assigns a random User Priority. This is useful for testing purposes.

This module allows to configure network scenarios at layer 2. The STP and RSTP related parameters such as link cost, port priority and the "is-edge" flag can be configured with XML files.

This module has one instance per network node, and it acts like a bridge between the node and the network's global configurator module, L2NetworkConfigurator.

Interface for Ethernet MAC implementations. All Ethernet MAC implementations should implement this (i.e. declared as: EtherMAC like IEtherMAC). The existing implementations are these: EtherMAC and EtherMACFullDuplex.

This module interface provides an abstraction for both upper and lower interfaces of different link layers.

This module interface provides an abstraction for the lower interface of different link layers.

This module interface provides an abstraction for the upper interface of different link layers.

Interface for MAC address tables

This interface provides an abstraction for different network protocols.

Prototype for modules providing Ethernet switch functionality. These modules handle the mapping between ports and MAC addresses, and forward frames (EtherFrame) to appropriate ports.

Module interface for Spanning Tree protocols

This is the interface of traffic conditioner modules.

Prototype module for link layer protocols.

Generic CSMA protocol supporting Mac-ACKs as well as constant, linear or exponential backoff times.

Implements an imaginary CSMA/CA-based MAC protocol with optional acknowledgements and a retry mechanism. With the appropriate settings, it can approximate basic 802.11b ad-hoc mode operation.

Implements the shared coaxial cable for classic Ethernet.

Performs Ethernet II or Ethernet with SNAP encapsulation/decapsulation.

Dummy encapsulation/decapsulation module for EthernetInterface.

Simple classifier, that forwards EtherPauseFrames to the pauseOut gates, and other frames to the defaultOut gate.

A generic wiring hub model.

Provides Ethernet 802.3 encapsulation/decapsulation and dispatching to the appropriate higher layer by DSAP values.

Ethernet MAC layer. MAC performs transmission and reception of frames. See the IEtherMAC for the Ethernet MAC layer general informations. Doesn't do encapsulation/decapsulation; see EtherLLC and EtherEncap for that.

Ethernet MAC which supports full-duplex operation ONLY. See the IEtherMAC for general informations.

Ethernet network interface. Complements EtherMAC and EtherEncap with an output queue for QoS and RED support.

Queue module that gives the PAUSE frames a higher priority, and can be parametrized with an IOutputQueue for serving the other frames.

Module interface for Ethernet encapsulation/decapsulation.

This module handles the mapping between ports and MAC addresses.

Implements an interface that corresponds to a real interface on the host running the simulation. Suitable for hardware-in-the-loop simulations.

Implements a trivial MAC layer for use in IdealWirelessNic.

Highly abstracted wireless NIC that consists of a unit disk radio and a trivial MAC protocol. It offers simplicity for scenarios where Layer 1 and 2 effects can be completely ignored, for example testing the basic functionality of a wireless ad-hoc routing protocol.

This NIC implements an 802.11 network interface card. It can be configured via the mgmtType parameter to act as an AP or a STA, or for ad-hoc mode.

Module interface for all ieee802.11 mac modul

Delegate some upperMac parameters to Ieee80211Mac, to be more compatible with the old MAC. NOTE: NOT ALL PARAMETERS OF THE OLD MAC CAN BE MAPPED.

Implementation of the 802.11b MAC protocol. This module is intended to be used in combination with the Ieee80211Radio module as the physical layer. (The SnrEval80211 and Decider80211 modules should also work if per-packet bitrate setting gets implemented.)

near copy-paste of inet.linklayer.base.MACProtocolBase to work around "compound-module cannot extend a simple-module" error in OMNeT++ 4.x

near copy-paste of inet.linklayer.base.MACProtocolBase to work around "compound-module cannot extend a simple-module" error in OMNeT++ 4.x

The default implementation of IRx.

The default implementation of ITx.

IEEE 802.11 Enhanced Distributed Channel Access Function

The default implementation of IContention.

Interface for collision controllers. A collision controller is used with EDCA, and it detects and reports internal collisions between Contention instances.

Interface for modules that implement contention-based channel access. For each frame, Contention listens on the channel for a DIFS (AIFS) period then for a random backoff period before transitting the frame, and defers when busy channel is sensed. After receiving a corrupted frame, EIFS is used instead of the original DIFS (AIFS).

Interface for auto rate control modules.

Interface for frame rate selection modules.

Interface for Rx processes. The Rx process checks received frames for errors, manages the NAV, and notifies Tx processes about the channel state (free or busy). The channel is free only if it is free according to both the physical (CCA) and the virtual (NAV-based) carrier sense algorithms. Correctly received frames are sent up to UpperMac (see IUpperMac), corrupted frames are discarded. Tx processes are also notified about corrupted and correctly received frames. so they can switch between using DIFS/AIFS and EIFS according to the channel access procedure.

Interface for MAC statistics collection modules

Interface for processes that unconditionally transmit a frame after waiting for a specified inter-frame space (usually SIFS). Such processes can be used to transmit frames where no contention is needed, e.g. ACK, CTS, or the second and further frames of a TXOP.

IEEE 802.11 Distributed Coordination Function

HCF -- Hybrid Coordination Function

IEEE 802.11 Mesh Coordination Function

IEEE 802.11 Point Coordination Function

References: [1] ftp://ftp-sop.inria.fr/planete/ivs/papers/mswim04.pdf [2] http://research.microsoft.com/en-us/projects/mesh/mobicom01.pdf "However, there is a clear threshold region in the 40ms-60ms range, depending on the degree of mobility, beyond which there is little performance change but below which there is a noticeable drop."

The default implementation of IStatistics

Used in 802.11 infrastructure mode: in a station (STA), this module controls channel scanning, association and handovers, by sending commands (e.g. Ieee80211Prim_ScanRequest) to the management module (Ieee80211MgmtSTA).

802.11 management module used for ad-hoc mode. Relies on the MAC layer (Ieee80211Mac) for reception and transmission of frames.

Used in 802.11 infrastructure mode: handles management frames for an access point (AP). It relies on a connected Ieee80211Mac for actual reception and transmission of frames.

Used in 802.11 infrastructure mode: handles management frames for an access point (AP). It relies on a connected Ieee80211Mac for actual reception and transmission of frames.

Used in 802.11 infrastructure mode: handles management frames for a station (STA).

Used in 802.11 infrastructure mode: handles management frames for a station (STA). Relies on the MAC layer (Ieee80211Mac) for reception and transmission of frames.

This is not a concrete module type, but a prototype for all IEEE 802.11 management module types. It exists to specify what gates a management module should have in order to be usable within Ieee80211Nic.

This modul forwards frames (EtherFrame) based on their destination MAC addresses to appropriate ports.

Implements the Rapid Spanning Tree Protocol (IEEE 802.D-2004) for IEC 48-bit MAC addresses. It is a complete implementation except it doesn't fall back to STP when peers don't support RSTP.

The Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for any bridged Ethernet local area network. The basic function of STP is to prevent bridge loops and the broadcast radiation that results from them. Spanning tree also allows a network design to include spare (redundant) links to provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links.

Network tester module Show if a network topology is loopfree, all nodes are connected or it has tree topology

Implementation of L-MAC (Lightweight Medium Access Protocol for Wireless Sensor Networks)

Loopback interface module implementation.

Loopback interface. Complements the Loopback module.

PPP implementation.

PPP interface. Complements the PPP module with an output queue for QoS and RED support.

Implementation of X-MAC. See C++ documentation for details.

Abstract base module for mobility models.

Abstract base module for mobility models.

The module interface for mobility models.

This is the coordinator module of the MoBAN mobility model. It should be instantiated in the top level simulation network in MiXiM, once per WBAN. The coordinator module is the main module that provides the group mobility and correlation between nodes in a WBAN. In the initialization phase, it reads three user defined input files which are the postures specification file, a configuration file which includes all required parameter for specific distributions, and the previously logged mobility pattern, if it is requested to use a logged pattern. Note that all WBAN instances may use the same input files if they are exactly in the same situation.

This is the local mobility module of MoBAN. It should be instantiated in each node that belongs to a WBAN. The NED parameter "coordinatorIndex" determine to which WBAN (MoBANCoordinator) it belongs. The current implementation uses the Random Walk Mobility Model (RWMM) for individual (local) movement with a sphere around the node, with given speed and sphere radius of the current posture. The reference point of the node it the current posture, the sphere radius, and the speed is given by the corresponding coordinator. RWMM determines the location of node at ant time relative to the given reference point.

Uses the <position_change> elements of the ANSim tool's trace file.

Uses the native file format of BonnMotion (http://www.cs.uni-bonn.de/IV/BonnMotion/).

Uses a probabilistic transition matrix to change the state of motion. In this model, the state of the mobile node in each direction (x and y) can be:

Moves the node around a circle.

Controls all movement related things of a host

Uses a Gauss-Markov model to control the randomness in the movement. Totally random walk (Brownian motion) is obtained by setting alpha=0, while alpha=1 results a linear motion.

This is a linear mobility model with speed, angle and acceleration parameters. Angle only changes when the mobile node hits a wall: then it reflects off the wall at the same angle.

Mobility model which places all hosts at constant distances in a line with an orientation

This is a random mobility model for a mobile host with a mass. It is the one used in "Optimized Smooth Handoffs in Mobile IP" by Perkins &Wang.

TODO: why does this comment refer to BonnMotion instead of NS2?

Random Waypoint mobility model.

Moves the node around a rectangle.

Moves a tractor through a field with a certain amount of rows. Since the tractor also moves around the field, the tractor travels the number of rows PLUS one rows. Consider the following piece of ascii-art for rows=2.

A LOGO-style movement model, with the script coming from XML. It can be useful for describing random as well as deterministic scenarios.

Places all hosts on concentric circles

Places all hosts in a rectangular grid. The usable area (constraint area minus margins on each side) is split into smaller cells (with separationX,separationY size). Hosts are placed in the middle of each cell. By default, the number of columns and rows follow the aspect ratio of the usable area. By default stepX and stepY are calculated based on the number of columns and rows.

This mobility module does nothing; it can be used for stationary nodes.

TODO

Implements the Address Resolution Protocol for IPv4 and IEEE 802 6-byte MAC addresses.

TODO

Module base for different network protocols.

This module provides a mechanism to test network layer connectivity using echo request/response messages similar to that of ICMP.

Keeps the table of network interfaces.

This module provides a simple network layer.

Adds routes to a GenericRoutingTable similarly how IPv4NetworkConfigurator adds static routes to IPv4RoutingTable.

Configures IPv4 addresses and routing tables for a "flat" network, "flat" meaning that all hosts and routers will have the same network address and will only differ in the host part.

HostAutoConfigurator automatically assigns IP addresses and sets up routing table. It has to be added into each host.

This module assigns IP addresses and sets up static routing for an IPv4 network. It assigns per-interface IP addresses, strives to take subnets into account, and can also optimize the generated routing tables by merging routing entries.

This module has one instance per network node, and it acts like a bridge between the node and the network's global configurator module, IPv4NetworkConfigurator.

Configures IPv6 addresses and routing tables for a "flat" network, "flat" meaning that all hosts and routers will have the same network address and will only differ in the host part.

TODO

\IPv6 Tunnel Manager

This module interface provides an abstraction for the upper and lower interfaces of different network layers.

This module interface provides an abstraction for the lower interface of different network layers.

This module interface provides an abstraction for the upper interface of different network layers.

This interface provides an abstraction for different network protocols.

This module interface provides an abstraction for different routing tables.

Module interface for xMIPv6 (where x = F, H, F-H).

This is an example queue, that implements one class of the Assured Forwarding PHB group (RFC 2597).

This module reads the DSCP (lower six bits of ToS/TrafficClass) from the received datagram, and forwards the datagram to the corresponding output gate.

This is an example queue, that can be used in interfaces of DS core and edge nodes to support the AFxy (RFC 2597) and EF (RFC 3246) PHBs.

This module sets the DSCP field (lower six bit of Tos/TrafficClass) of IP datagrams to the value specified by the dscps parameter.

This classifier contains a list of filters that identifies the flows and determines their classes. Each filter can match the source and destination address, IP protocol number, source and destination ports, or ToS of the datagram. The first matching filter determines the index of the out gate. If no matching filter is found, then the packet will be sent through the defaultOut gate.

This module implements a Single Rate Three Color Meter (RFC 2697).

Simple token bucket meter.

This module implements a Two Rate Three Color Meter (RFC 2698).

A simple flooding protocol for network-level broadcast.

This module provides the generic network layer.

This module is a simplified generic network protocol that routes generic datagrams using different kind of network addresses.

This module stores generic routes used by the generic network protocol.

ICMPv6 implementation.

Implements IPv6 Neighbour Discovery.

Delay module interface for InternetCloud.

Utility channel for InternetCloud. Tags packets with an "incomingInterfaceID" parameter.

Delay module for InternetCloud. This is essentially equivalent to a full graph with edges being differently configured DatarateChannels. It delays and/or drops incoming packets based on rules specified in an xml configuration.

Handles error notifications that arrive from other protocol modules.

ICMP implementation

Imlementation of IGMPv2 protocol. Multicast routers use IGMP to learn which groups have members on each of their attached physical networks.

Imlementation of IGMPv2 protocol. Multicast routers use IGMP to learn which groups have members on each of their attached physical networks.

Module interface for IGMP modules.

Implements the IPv4 protocol. The protocol header is represented by the IPv4Datagram message class.

Network layer of an IPv4 node.

Stores the routing table. (Per-interface configuration is stored in InterfaceTable.)

NetworkInfo does not send or receive messages and has no parameters either. Instead it is invoked from ScenarioManager scripts. E.g.:

Records changes in the routing tables (IPv4RoutingTable) and interface tables (InterfaceTable) of all hosts and routers. The filename has to be specified in the routinglog-file configuration option that this module registers.

Implements basic IPsec (RFC 4301) functionality. It supports Authentication Header (AH) and Encapsulating Security Payload (ESP), in transport mode, for IPv4 unicast traffic (UDP/TCP/ICMP). A simple performance model to account for the overhead of cryptography is included. The IPsec databases SPD and SAD are stored in separate modules (SecurityPolicyDatabase, SecurityAssociationDatabase).

Represents the IPsec Security Association Database (SAD). The database is filled by the IPsec module.

Represents the IPsec Security Policy Database (SPD). The database is filled by the IPsec module.

Implements the IPv6 protocol.

Handles error notifications that arrive from other protocol modules.

Represents an IPv6 network layer (L3).

IPv6 Routing Table and Neighbour Discovery data structures. NOTE: This component MUST be named as "routingTable6" inside a StandardHost/Router etc. in order to be accessible by the IPv6 and other modules

\IPv6 Tunnel Manager

Handles and processes LDP messages.

Stores the LIB (Label Information Base), accessed by MPLS and its associated control protocols (RSVP, LDP) via direct C++ method calls.

Implements the MPLS protocol.

This module supports multiple different network layers simultaneously. Packets received through the transport gates are handed over to the corresponding network layer based on the attached control info. Packets received from the interface gates are also handed over to the corresponding network layer based on their runtime type.

This module provides network protocol specific multiplexing. It's part of MultiNetworkLayer and it's meant to be used there.

This module provides network protocol specific multiplexing. It's part of MultiNetworkLayer and it's meant to be used there.

This module supports multiple different routing tables simultaneously. The actual routes are stored in the submodule routing tables and they are accessed directly by modules.

This module provides network protocol specific multiplexing.

Multi-hop ad-hoc data dissemination protocol based on probabilistic broadcast, with adaptive parameters.

Multi-hop ad-hoc data dissemination protocol based on probabilistic broadcast.

Implements RSVP-TE, a signalling protocol for MPLS. The module processes RSVP-TE messages, installs labels and does the reservation along LSP paths.

TODO documentation

This module implements a very minimalistic link state routing protcol. Apart from the basic topology information, the current link usage is distributed to all participants in the network (by means of flooding).

Traffic Engineering Database. Stores network topology with detailed link information, including total and reserved bandwidths.

Wiseroute is a simple loop-free routing algorithm that builds a routing tree from a central network point, designed for sensor networks and convergecast traffic.

This module provides a simple network layer.

xMIPv6 Data structure for the HA and CN(s) only.

xMIPv6 Data structure for the Mobile Node

Implements xMIPv6 (where x = F, H, F-H).

Implements xMIPv6 (where x = F, H, F-H).

It models a WirelessHost extended with AODVRouting submodule.

IP router with BGPv4 and OSPFv4 support.

TODO

100 gigabit/sec Ethernet link

100 megabit/sec Ethernet link

10 gigabit/sec Ethernet link

10 megabit/sec Ethernet link

1 gigabit/sec Ethernet link

40 gigabit/sec Ethernet link

An example host with one Ethernet port and a traffic generator that generates request-reply traffic directly over Ethernet. This host model does not contain higher layer protocols (IP, TCP). By default it is configured to use half-duplex MAC (CSMA/CD).

An example host with one Ethernet interface and an Ethernet traffic generator directly connected to it. This host model does not contain higher layer protocols (IP, TCP). By default is configured to use half-duplex MAC (CSMA/CD).

Base for Ethernet link types. Propagation delay can be specified with the length of the cable, i.e. in meters instead of nanoseconds or microseconds.

Model of an Ethernet switch.

TODO

Simple host for the HttpTools project. The module is derived from the INET StandardHost module. All network infrastructure modules were removed; the node is a simple container for tcpApps. Suitable apps are the HttpBrowserDirect and HttpServerDirect modules from HttpTools. See the INET documentation for StandardHost and the provided examples on how to assign tcpApps to the module.

A wireless host containing routing, mobility and battery components. Supports only IPv4 protocol, TCP and UDP as transport protocol. This is a typical mobile node which can participate in adhoc routing and may have TCP/UDP applications installed. Supports ICMP (ping) too.

Contains the common interface for all node types in a network.

Contains the common lower layers (linklayer and networklayer) of Router, StandardHost, WirelessHost etc.

IPv4 router that supports wireless, Ethernet, PPP and external interfaces. By default, no wireless and external interfaces are added; the number of Ethernet and PPP ports depends on the external connections.

IPv4 host with SCTP, TCP, UDP layers and applications. IP forwarding is disabled by default (see forwarding).

Models a host with (default) one wireless (802.11) card in infrastructure mode. This module is basically a StandardHost with an Ieee80211Nic with mgmtType = Ieee80211MgmtSTA added. It should be used in conjunction with AccessPoint, or any other AP model which contains Ieee80211Nic with mgmtType = Ieee80211MgmtAP.

This module is an IPv4 router that can delay or drop packets (while retaining their order) based on which interface card the packet arrived on and on which interface it is leaving the cloud. The delayer module is replacable.

IPv6 router.

IPv6 host with TCP, SCTP and UDP layers and applications. see StandardHost for configuration.

An LDP-capable router.

An RSVP-TE capable router.

An OSPFv2 router.

IPv4 host with SCTP, TCP, UDP layers and a packetdrill application. The application has a direct connection to the TunInterface.

An RIPv2 router.

TODO document!

A generic access point supporting multiple wireless radios, and multiple ethernet ports. The type of the ethernet MAC, relay unit and wireless card can be specified as parameters.

An IPv6 host with MIPv6 support and contains a Binding Cache which gets updated with every BU received.

IPv6 router Configured to operate as a Home Agent in a network supporting MIPv6.

MIPv6 host with TCP, UDP layers and applications.

IPv6 compatible node with MIPv6 support. Models a host with one wireless (802.11b) card in infrastructure mode, supports handovers and MIPv6 protocol. This module is basically a StandardHost with an Ieee80211NicSTA and MobileIPLayer6 added. It should be used in conjunction with WirelessAPSimplified, or any other AP model which contains Ieee80211NicAPSimplified.

This analog model computes with dimensional analog power representation. In other words the signal power may change over time and/or frequency.

This analog model computes with scalar analog power representation. In other words, the signal power does not change over time or frequency, except for the boundaries of the signal.

This antenna model describes an antenna that has an antenna gain indepent of the transmission or reception direction.

This module represents the cosine antenna model found in

This antenna model describes the well-known dipole antenna or doublet. It consists of two identical conductive elements, which are bilaterally symmetrical.

This antenna model computes the antenna gain from the direction of the signal using linear interpolation for all 3 euler angles independently of each other. The gain parameters contain a sequence of angle [degree] and gain [dB] pairs. The first pair must be at 0 [degree].

This antenna model describes the theoretical point source which radiates the same intensity of radiation in all directions.

This model is based on a parabolic approximation of the main lobe radiation pattern. A similar model appears in

This module is part of a simple hypothetical layered receiver. It computes the packet domain representation from the bit domain representation by applying the configured descrambling, forward errror correction decoding, and deinterleaving.

This module is part of a simple hypothetical layered receiver. It computes the bit domain representation from the symbol domain representation by applying the configured modulation.

This module is part of a simple hypothetical layered transmitter. It computes the bit domain representation from the packet domain representation by applying the configured scrambling, forward errror correction encoding, and interleaving.

This medium model is used by a simple hypothetical layered radio.

This receiver model is part of a simple hypothetical layered radio. It receives detailed transmissions that have separate representation for all simulated domains. The levelOfDetail parameter controls which domains are actually simulated, but all parameters relevant to the error model are expected to be set on the reception.

This medium model is used by a simple hypothetical layered radio.

This transmitter model is part of a simple hypothetical layered radio. It produces detailed transmissions that have separate representation for all simulated domains. The levelOfDetail parameter controls which domains are actually simulated, but all parameters relevant to the error model are always set on the transmission.

This module is part of a simple hypothetical layered transmitter. It computes the symbol domain representation from the bit domain representation by applying the configured modulation.

This error model computes the erroneous bits, symbols, or simply whether the packet is error free or not based on the SNIR.

This radio model provides a hypothetical radio that simply uses one of the well-known modulations without utilizing other techiques such as forward error correction, interleaving, spreading, etc. It must be used in conjunction with the APSKDimensionalRadioMedium model.

This radio medium model provides a hypothetical radio that simply uses one of the well-known modulations without utilizing other techiques such as forward error correction, interleaving, spreading, etc. It must be used in conjunction with the APSKDimensionalRadio model.

This receiver model receives a transmission succesfully if the minimum of the signal to noise and interference ratio over the duration of the reception is sufficiently high. It uses the error model to compute the error rate based on this value and the used modulation.

This transmitter model produces transmissions that use dimensional transmission power (that changes over time and/or frequency) in their analog representation and the configured modulation.

This radio model provides a hypothetical radio that simply uses one of the well-known modulations without utilizing other techiques such as forward error correction, interleaving, spreading, etc.

This radio model provides a hypothetical radio that simply uses one of the well-known modulations without utilizing other techiques such as forward error correction, interleaving, spreading, etc. It must be used in conjunction with the APSKScalarRadioMedium model.

This radio medium model provides a hypothetical radio that simply uses one of the well-known modulations without utilizing other techiques such as forward error correction, interleaving, spreading, etc. It must be used in conjunction with the APSKScalarRadio model.

This receiver model receives a transmission succesfully if the minimum of the signal to noise and interference ratio over the duration of the reception is sufficiently high. It uses the error model to compute the error rate based on this value and the used modulation.

This transmitter model produces transmissions that have scalar transmission power in their analog representation and the configured modulation.

This error model determines packet error rate, bit error rate, and symbol error rate by using the well-known formula that corresponds to the modulation. It assumes no forward error correction or any other techinque is used in the physical signal.

This background noise model describes noise that does not change over space, time and frequency. It produces dimensional noise signals that can be further used in dimensional computations.

This background noise model describes noise that does not change over space, time and frequency. It produces scalar noise signals that can be further used in scalar computations.

This module servces as the base module for antenna models.

This transmitter model produces transmissions that use dimensional transmission power (that changes over time and/or frequency) in their analog representation and the configured modulation.

This module servces as the base module for error models.

This module servces as a base module for flat radio models.

This module servces as a base module for narrowband radio models.

This module servces as a base module for narrowband receiver models.

This module servces as a base module for narrowband transmitter models.

This module servces as a base module for propagation models.

This module servces as a base module for tracing obstacle loss models.

Scrambler module converts an input string into a seemingly random output string of the same length.

Transfer function (octal) matrix ================================

The radio model describes the physical device that is capable of transmitting and receiving signals on the medium. It contains an antenna model, a transmitter model, a receiver model, and an energy consumer model.

The medium model describes the shared physical medium where communication takes place. It keeps track of radios, noise sources, ongoing transmissions, background noise, and other ongoing noises. The medium computes when, where and how transmissions and noises arrive at receivers. It also efficiently provides the set of interfering transmissions and noises for the receivers.

This communication cache model stores radio, transmission and reception related intermediate computation results in map data structures. It's primarily useful for simulations with both static *and* dynamic radios, and with both short *and* long transmission durations.

This communication cache model allows validating other implementations. It can be used to provide a reference for communication logs, simulation fingerprints, and statistical results that can be compared with results of other communication cache implementations.

This communication cache model stores radio, transmission and reception related intermediate computation results in vector data structures. It's primarily useful for simulations with *either* static *or* short lived dynamic radios, and with only short transmission durations.

The analog model describes how the analog representation of the transmissions is turned into the analog representation of the receptions.

The antenna model describes the physical device (a part of the radio) which converts electric signals into radio waves, and vice versa.

The error model describes how the signal to noise ratio affects the amount of errors at the receiver.

The neighbor cache model computes the affected set of receivers on the medium for a given transmission.

The obstacle loss model describes the reduction of power as the signal passes through physical objects.

The path loss model describes the reduction of power as the signal propagates through space.

This module interface provides an abstraction for the interface of different physical layers.

The propagation model describes how a radio signal propagates through space over time.

Prototype for radio modules. Radio modules deal with the transmission of frames over a wireless medium (the radio medium).

The background noise model describes the thermal noise, the cosmic background noise, and other random fluctuations of the electromagnetic field that affect the quality of the communication channel.

The medium model describes the shared physical medium where communication takes place. It keeps track of radios, noise sources, ongoing transmissions, background noise, and other ongoing noises. The medium computes when, where and how transmissions and noises arrive at receivers.

The receiver model describes the physical process which converts electric signals into packets.

The transmitter model describes the physical process which converts packets into electric signals.

This module provides a radio energy consumer model. The current consumption is determined by the radio mode, the transmitter state and the receiver state using constant parameters.

This module provides a radio power consumer model. The power consumption is determined by the radio mode, the transmitter state and the receiver state using constant parameters.

This error model provides parameters to specify the constant packet error rate, bit error rate, and symbol error rate for receptions independent of any interfering transmission or noise.

This analog model provides a very simple and predictable physical layer behavior. It determines the reception power by categorizing transmissions based on the distance between the transmitter and the receiver. It doesn't support noise and signal to noise ratio calculations.

This radio model provides a very simple but fast and predictable physical layer behavior. It must be used in conjunction with the IdealRadioMedium model.

This radio medium model provides a very simple but fast and predictable physical layer behavior. It must be used in conjunction with the IdealRadio model.

This receiver model receives a transmission succesfully within communication range unless there's another interfering transmission within interference range. It also supports an ideal communication channel with configuring the receiver to ignore interfering transmissions.

This transmitter model produces transmissions that are parameterized with communication range, interference range, and detection range. It also supports an ideal communication channel with configuring the range parameters to infinity.

Please check the

See also: Ieee80211LayeredOFDMTransmitter documentation first, since this receiver module is symmetric to it.

The level of detail parameter determines which submodules of the transmitter will be used:

This is the decoder module for the layered IEEE 802.11 OFDM PHY infrastructure (IEEE 802.11-2012, Clause 18).

See also: Ieee80211OFDMModulator

This is the encoder module for the layered IEEE 802.11 OFDM PHY infrastructure (IEEE 802.11-2012, Clause 18).

The Ieee80211OFDMInterleaver is defined by a two-step permutation. The first permutation ensures that adjacent coded bits are mapped onto nonadjacent subcarriers. The second ensures that adjacent coded bits are mapped alternately onto less and more significant bits of the constellation and, thereby, long runs of low reliability (LSB) bits are avoided. (IEEE 802.11, 18.3.5.7 Data interleaving)

This is an IEEE 802.11 OFDM modulator module, the implementation is based on 18.3.5.8 Subcarrier modulation mapping section in IEEE 802.11-2012 Std.

This is the error model for the layered IEEE 802.11 OFDM PHY infrastructure (IEEE 802.11-2012, Clause 18). OFDM means that the physical layer uses OFDM modulation.

This radio model uses dimensional transmission power (that changes over time and/or frequency) in the analog representation. It must be used in conjunction with the Ieee80211DimensionalRadioMedium model.

This radio medium model uses dimensional transmission power (that changes over time and/or frequency) in the analog representation. It must be used in conjunction with the Ieee80211DimensionalRadio model.

This receiver model receives an IEEE 802.11 transmission successfully if the minimum of the signal to noise and interference ratio over the duration of the reception is sufficiently high. It uses one of the IEEE 802.11 specific error models to compute the error rate based on this value and the used operation mode.

This transmitter model produces IEEE 802.11 transmissions that have dimensional transmission power (that changes over time and/or frequency) in their analog representation. The bit domain, symbol domain, and sample domains of the transmissions are not represented.

This radio model uses ideal analog representation. It must be used in conjunction with the IdealRadioMedium model.

See also Ieee80211IdealTransmitter, Ieee80211IdealRadio, and IdealRadioMedium.

See also Ieee80211IdealReceiver, Ieee80211IdealRadio, and IdealRadioMedium.

This radio model is part of the IEEE 802.11 physical layer model. It supports multiple channels, different operation modes, and preamble modes. It must be used in conjunction with the Ieee80211RadioMedium model or other derived models.

This radio medium model is part of thee IEEE 802.11 physical layer model. It must be used in conjunction with the Ieee80211Radio model or other derived models.

This receiver model serves as the base module for IEEE 802.11 receivers. It supports switching channels, configuring different operation modes, and preamble modes.

This radio model uses scalar transmission power in the analog representation. It must be used in conjunction with the Ieee80211ScalarRadioMedium model.

This radio medium model uses scalar transmission power in the analog representation. It must be used in conjunction with the Ieee80211ScalarRadio model.

This receiver model receives an IEEE 802.11 transmission successfully if the minimum of the signal to noise and interference ratio over the duration of the reception is sufficiently high. It uses one of the IEEE 802.11 specific error models to compute the error rate based on this value and the used operation mode.

This transmitter model produces IEEE 802.11 transmissions that have scalar transmission power in their analog representation. The bit domain, symbol domain, and sample domains of the transmissions are not represented.

This transmitter model serves as the base module for IEEE 802.11 transmitters. It supports switching channels, configuring different operation modes, and preamble modes.

This neighbor cache model organizes radios in a 3 dimensional grid with constant cell size and updates periodically.

This neighbor cache model maintains a separate periodically updated neighbor list for each radio.

This neighbor cache model organizes radios in a 2 dimensional quad tree (ignoring the Z axis) with constant node size and updates periodically.

This obstacle loss model determines the power loss by computing the accurate dielectric and reflection loss along the straight path considering the shape, the position, the orientation, and the material of obstructing physical objects.

This obstacle loss model determines power loss by checking if there is any obstructing physical object along the straight propagation path. The result is either total power loss if there was such an object or no loss at all if there wasn't.

This propagation model computes the propagation time to be proportional to the traveled distance, the ratio is determined by the constant propagation speed parameter.

This propagation model computes the propagation time to be independent of the traveled distance. In other words, the propagation time is determined by a constant parameter.

This is an abstract base module for current based energy consumer models. It defines shared signals and statistics.

This is an abstract base module for current based energy generator models. It defines shared signals and statistics.

This is an abstract base module for current based energy sink models. It defines signals and statistics.

This is an abstract base module for current based energy source models. It defines shared signals and statistics.

This is an abstract base module for current based energy storage models. It defines shared signals and statistics.

This is an abstract base module for power based energy consumer models. It defines shared signals and statistics.

This is an abstract base module for power based energy generator models. It defines shared signals and statistics.

This is an abstract base module for power based energy sink models. It defines signals and statistics.

This is an abstract base module for power based energy source models. It defines shared signals and statistics.

This is an abstract base module for power based energy storage models. It defines shared signals and statistics.

This energy consumer model alternates between two modes called consumption and sleep mode. In consumption mode it consumes a randomly selected constant power for a random time interval. In sleep mode it doesn't consume energy for another random time interval.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with current [A], and storage capacity with charge [C] and output voltage [V]. The Cc is an abbreviation that is used for charge and current based interfaces.

The energy consumer models describe the energy consumption process of devices over time. For example, a radio consumes energy when it transmits or receives signals, or a CPU consumes energy when the network layer processes packets, or a display consumes energy when it's turned on, etc.

The energy generator models describe the energy generation process of devices over time. A solar panel, for example, produces energy based on time, the panel's position on the globe, its orientation towards the sun and the actual weather conditions.

The energy management models monitors an energy storage, estimates its state, and controls the consumers and generators to protect the energy storage from operating outside its safe operating area.

The energy sink models absorb energy from multiple energy generators.

The energy source models provide energy for multiple energy consumers.

The energy storage models describe devices that absorb energy produced by generators, and provide energy for consumers. For example, an electrochemical battery in a mobile phone provides energy for its display, its CPU, and its wireless communication device. It can also absorb energy produced by a solar panel installed on its display, or by a portable charger plugged into a wall socket.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This interface extends the corresponding energy model interface. It requires implementations to describe energy consumption and energy generation with power [W] and storage capacity with energy [J]. The Ep is an abbreviation that is used for energy and power based interfaces.

This energy generator model alternates between two modes called generation and sleep mode. In generation mode it generates a randomly selected constant power for a random time interval. In sleep mode it doesn't generate energy for another random time interval.

This energy mangement model estimates the residual energy capacity of the energy source model by actually querying it. It is only useful when the estimation process is not important. This model initiates node shutdown when the residual capacity decreases below a threshold, and it also initiates node start when the residual capacity increases above another threshold.

This energy storage model stores an infinite amount of energy. It can provide energy for any number of consumers, and it can absorb energy from any number of generators. The ideal energy storage never gets completely charged or depleted. This module is primarily useful for testing energy consumer and energy generator models. See the base module for signals and statistics.

This battery model maintains a residual charge capacity by integrating the difference between the total consumed current and the total generated current over time. This model uses a charge independent ideal voltage source and an charge independent internal resistance. It initiates node crash when the residual charge capacity reaches zero. See the base module for signals and statistics.

This energy storage model maintains a residual energy capacity by integrating the difference between the total consumed power and the total generated power over time. It initiates node crash when the residual energy capacity reaches zero. This model doesn't have various properties such as self-discharge, memory effect, overcharging, temperature-dependence, etc. that real world batteries have. See the base module for signals and statistics.

Ad hoc On-Demand Distance Vector Routing Protocol module.

Implements BGP Version 4. TODO config file!

Interface for BGP routing module.

Interface for routing protocol modules connected to IP Layer.

This module provides Dynamic MANET On-demand (DYMO also known as AODVv2) Routing based on the IETF draft at http://tools.ietf.org/html/draft-ietf-manet-dymo-24.

This module interface is used by DYMO implementations.

This module provides DYMO routing for multiple network protocols simultaneously.

This module provides Greedy Perimeter Stateless Routing for Wireless Networks. The implementation supports both GG and RNG planarization algorithms.

This module interface is used by GPSR implementations.

This module provides GPSR routing for multiple network protocols simultaneously.

Implements the OSPFv4 routing protocol.

PIMSplitter module dispatches PIM packets received from the network layer according to the PIM mode of the incoming interface. Bu using a PIMSplitter it is possible to build nodes that operates in Dense Mode on some interfaces, and in Sparse Mode on others.

Implementation of PIM-DM protocol (RFC 3973).

Implementation of PIM-SM protocol (RFC 4601).

The PIMInterfaceTable module contains the PIM specific configuration parameters and state of the interfaces on which PIM is enabled.

The PIMNeighborTable module contains information about neighboring PIM routers.

Routing Information Protocol.

Module base for different transport protocols.

Interface for SCTP protocol.

Interface for TCP protocol implementations. All TCP implementations should implement this (i.e. declared as: TCP like ITCP) The existing implementations are these: TCP, TCP_NSC and TCP_lwIP.

UDP protocol interface.

Interface for RTP Payload Receivers.

Interface for RTP Payload Senders.

RTCP end system.

Audio-Video RTP Profile. RTPAVProfile is internal to the RTP module; instances are created and connected dynamically by RTP.

Generic RTP Profile. RTPProfile is internal to the RTP module; instances are created and connected dynamically by RTP.

Implements the SCTP protocol.

SCTPNatHook module.

\IP router.

TCP protocol implementation. See the ITCP for the TCP layer general informations.

Sends fabricated TCP packets. This is a base implementation, you'll probably have to customize it in C++ according to what you want to send and when you want to send it.

TCP model based on the LWIP 1.3.2 project. The original LWIP is available on the http://savannah.nongnu.org/projects/lwip/ page.

UDP protocol implementation, for IPv4 and IPv6.

This is a base module for data link layer link visualizer simple modules. It keeps track of active links in a network. A link between two network node is considered active if a packet is sent recently between their link layers. Active links are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of active links is done in derived modules.

This is a base module for energy storage visualizer simple modules.

This is a base module for IEEE 802.11 association visualizer simple modules. It keeps track of wireless interface associations by subscribing to a number of signals at the provided subscription module.

This is a base module for submodule information visualizer simple modules. It displays some information on network nodes originating from one of their corresponding submodules. No information is displayed by default, see module parameters for how to enable the visualization. The actual visualization is done in derived modules.

This is a base module for interface table visualizer simple modules. It displays information of network interfaces at network nodes. Network interfaces are not displayed by default, see module parameters for how to enable the visualization.

This is a base module for link break visualizer simple modules. It keeps track of link breaks in a network. Link breaks are not displayed by default, see module parameters for how to enable the visualization. The actual visualization of link breaks is done in derived modules.

This is a base module for link visualizer simple modules. It keeps track of active links in a network. A link between two network node is considered active if a packet is sent recently between the corresponding layers. Active links are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of active links is done in derived modules.

This is a base module for radio medium visualizer simple modules. It keeps track of ongoing transmissions, ongoing receptions, and propagating signals.

This is a base module for mobility visualizer simple modules. It subscribes for the mobilityStateChanged signal at the module determined by the subscriptionModule parameter. The actual visualization of mobility is done in derived modules.

This is a base module for connection visualizer simple modules. The actual visualization of network connections is done in derived modules.

This is a base module for node visualizer simple modules. The actual visualization of network nodes is done in derived modules.

This is a base module for packet drop visualizer simple modules. It keeps track of dropped packets in a network. Packet drops are not displayed by default, see module parameters for how to enable the visualization. The actual visualization of packet drops is done in derived modules.

This is a base module for path visualizer simple modules. It keeps track of active routes in a network. A route between two node is considered active if a packet is sent recently between their corresponding layers. Active routes are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of active routes is done in derived modules.

This is a base module for physical environment visualizer simple modules. It provides the physical objects through the physical environment module for derived modules. The actual visualization of physical objects is done in derived modules.

This is a base module for physical layer link visualizer simple modules. It keeps track of active links in a network. A link between two network node is considered active if a packet is sent recently between their physical layers. Active links are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of active links is done in derived modules.

This is a base module for queue visualizer simple modules.

This is a base module for radio visualizer simple modules.

This is a base module for routing table visualizer simple modules. It displays routes in the routing tables of the network. Routes present are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of routes is done in derived modules.

This is a base module for scene visualizer simple modules on a 3D osg scene. It displays the playground either as a filled rectangle or as an image.

This is a base module for scene visualizer simple modules. It determines the bounds of the playground, that is the minimum area where the whole simulation fits in. The playground encloses all physical objects and the constraint area of all mobile nodes. The visualizer also provides a timer which can be used to periodically update the user interface independently of the underlying simulation. The actual visualization of the scene is done in derived modules.

This is a base module for statistic visualizer simple modules. It keeps track of the last value of a statistic for multiple network nodes. The actual visualization of statistic values is done in derived modules. It subscribes for the signal determined by the signalName parameter at the module specified by the subscriptionModule parameter. If the visualizer receives such a signal it checks if the source matches the sourceFilter parameter. If the signal passes the check it determines the last value of the statistic specified by the statisticName parameter.

This is a base module for tracing obstacle loss visualizer simple modules. It subscribes on the obstacle loss module for physical object penetrated signals. The actual visualization of obstacle loss is done in derived modules.

This is a base module for transport connection visualizer simple modules. It keeps track of open transport connections in a network. Open connections are not displayed by default, see the module parameters for how to enable the visualization. The actual visualization of transport connections is done in derived modules.

This is a base module for visualizer simple modules. It simply provides the visualization target module for derived modules.

This module visualizes some information of a submodule for each network node on a 2D canvas.

This module visualizes some information of a submodule for each network node on a 3D osg scene.

This module integrates canvas and osg info visualizers into a single module.

This module visualizes packet drops on a 2D canvas. It displays an icon for each packet drop in the network. See the documentation of the base module for what constitutes a packet drop.

This module visualizes packet drops on a 3D osg scene. It displays an icon for each packet drop in the network. See the documentation of the base module for what constitutes a packet drop.

This module integrates canvas and osg packet drop visualizers into a single module.

This module visualizes queues on a 2D canvas.

This module visualizes queues on a 3D osg scene.

This module integrates canvas and osg queue visualizers into a single module.

This module visualizes statistics on a 2D canvas. See the base module for how to configure which statistic is displayed. If configured properly, then it displays the last value of the statistic to the right of the visualization of the corresponding network node. The value and the unit is wrapped in a filled white rectangle.

This module visualizes a statistic on a 3D osg scene. See the base module for how to configure which statistic is displayed. If configured properly, then it displays the last value of the statistic just above the visualization of the corresponding network node. The value and the unit is wrapped in a filled rectangle.

This module integrates canvas and osg statistic visualizers into a single module.

This module interface allows configuring different IDataLinkVisualizer submodules from INI files. Such a visualizer displays the active data link layer links in a network.

This module interface allows configuring different IEnergyStorageVisualizer submodules from INI files. Such a visualizer displays energy storages.

This module interface allows configuring different IIeee80211Visualizer submodules from INI files. Such a visualizer displays IEEE 802.11 network interface associations.

This module interface allows configuring different IInfoVisualizer submodules from INI files. Such a visualizer displays various information from submodules of network nodes.

This module interface allows configuring different IIntegratedVisualizer submodules from INI files. Integrated visualizers are compound modules, they don't display anything on their own. Instead they combine multiple visualizers, most often simple modules, to provide a convenient way to add complex visualizations to a simulation.

This module interface allows configuring different IInterfaceTableVisualizer submodules from INI files. Such a visualizer displays various information for network interfaces present in the interface tables of a network.

This module interface allows configuring different ILinkBreakVisualizer submodules from INI files. Such a visualizer displays the data link breaks in a network.

This module interface allows configuring different IMediumVisualizer submodules from INI files. Such a visualizer displays transmitting nodes, receiving nodes, and propagating radio signals on a medium.

This module interface allows configuring different IMobilityVisualizer submodules from INI files. Such a visualizer updates the position (among others) of visual representations according to the corresponding mobility model.

This module interface allows configuring different INetworkConnectionVisualizer submodules from INI files. Such a visualizer creates the visual representations of network connections.

This module interface allows configuring different INetworkNodeVisualizer submodules from INI files. Such a visualizer creates the visual representations of network nodes.

This module interface allows configuring different INetworkRouteVisualizer submodules from INI files. Such a visualizer displays active network routes in a network.

This module interface allows configuring different IPacketDropVisualizer submodules from INI files. Such a visualizer displays the packet drops in a network.

This module interface allows configuring different IPhysicalEnvironmentVisualizer submodules from INI files. Such a visualizer displays the physical objects present in the physical environment.

This module interface allows configuring different IPhysicalLinkVisualizer submodules from INI files. Such a visualizer displays the active physical layer links in a network.

This module interface allows configuring different IQueueVisualizer submodules from INI files. Such a visualizer displays queues.

This module interface allows configuring different IRadioVisualizer submodules from INI files. Such a visualizer displays radios.

This module interface allows configuring different IRoutingTableVisualizer submodules from INI files. Such a visualizer displays routes present in the routing tables of a network.

This module interface allows configuring different ISceneVisualizer submodules from INI files. Such a visualizer displays the playground, the coordinate axes, sets up the initial viewpoint, etc.

This module interface allows configuring different IStatisticVisualizer submodules from INI files. Such a visualizer displays a statistic for multiple network nodes.

This module interface allows configuring different ITracingObstacleLossVisualizer submodules from INI files. Such a visualizer displays obstacle loss during wireless signal propagation.

This module interface allows configuring different ITransportConnectionVisualizer submodules from INI files. Such a visualizer displays the active transport connections in a network.

This module interface allows configuring different ITransportRouteVisualizer submodules from INI files. Such a visualizer displays active transport routes in a network.

This module visualizes a physical environment on a 2D canvas. It displays the physical objects present in the physical environment. Since this is not a 3D visualization, so the physical objects are projected to a 2D plane according to the view angle of the corresponding SceneCanvasVisualizer. Apart from this the visualizer considers all object properties that affect the appearance such as position, orientation, shape, colors, opacity, etc.

This module visualizes a physical environment on a 3D osg scene. It displays the physical objects present in the physical environment. The visualizer considers all object properties that affect appearance such as position, orientation, shape, colors, opacity, etc.

This module integrates canvas and osg physical environment visualizers into a single module.

This module integrates all canvas visualizers into a single module. It supports disabling any submodule visualizer by providing an empty string as its type.

This module integrates all osg visualizers into a single module. It supports disabling any submodule visualizer by providing an empty string as its type.

This module integrates canvas and osg visualizers into a single module.

This module visualizes data link layer links on a 2D canvas. It displays an arrow for each active link in the network. See the documentation of the base module for what constitutes an active link. The arrow points from the source towards the destination. If a link is used in both directions then there are separate arrows for them. Each arrow fades out over time as the link becomes inactive unless it is reinforced by another packet. The arrow automatically follows the movement of mobile nodes.

This module visualizes data link layer links on a 3D osg scene. It displays an arrow for each active link in the network. See the documentation of the base module for what constitutes an active link. The arrow points from the source towards the destination. If a link is used in both directions then there are separate arrows for them. Each arrow fades out over time as the link becomes inactive unless it is reinforced by another packet. The arrow automatically follows the movement of mobile nodes.

This module integrates canvas and osg data link visualizers into a single module.

This module visualizes IEEE 802.11 associations on a 2D canvas. It displays an icon labelled with the SSID for each associated wireless interface.

This module visualizes IEEE 802.11 associations on a 3D osg scene. It displays an icon labelled with the SSID for each associated wireless interface.

This module integrates canvas and osg IEEE 802.11 association visualizers into a single module.

This module visualizes interface tables on a 2D canvas. It displays a label for each selected network interface at the owner network node.

This module visualizes interface tables on a 3D osg scene. It displays a label for each selected network interface at the owner network node.

This module visualizes link breaks on a 2D canvas. It displays an icon for each link break in the network. See the documentation of the base module for what constitutes a link break. The icon is positioned at the middle point of the link.

This module visualizes link breaks on a 3D osg scene. It displays an icon for each link break in the network. See the documentation of the base module for what constitutes a link break. The icon is positioned at the middle point of the link.

This module integrates canvas and osg link break visualizers into a single module.

This module visualizes multiple mobilities on a 2D canvas. It moves visual representations according to their mobility model. It also displays recent movement as a polyline, current velocity vector and current orientation.

This module visualizes multiple mobilities on a 3D osg scene. It moves the visual represnetation according to their mobility model. It also displays recent movement as a polyline, current velocity vector and current orientation.

This module integrates canvas and osg mobility visualizers into a single module.

This module visualizes network routes on a 2D canvas. It displays an polyline arrow for each active route in the network. See the documentation of the base module for what constitutes an active route. The arrow points from the source towards the destination. If a link is used in both directions then there are arrowheads on both ends of the arrow. Each polyline fades out over time until the route becomes inactive unless it is reinforced by another packet. The polyline automatically follows the movement of mobile nodes.

This module visualizes network routes on a 3D osg scene. It displays an polyline for each active route in the network. See the documentation of the base module for what constitutes an active route. Each polyline fades out over time until the route becomes inactive unless it is reinforced by another packet. The polyline automatically follows the movement of mobile nodes.

This module integrates canvas and osg network route visualizers into a single module.

This module visualizes routes in the routing tables on a 2D canvas. It displays an arrow for each route in the routing tables of the network. The arrow points from the node containing the routing table towards the gateway. The arrow automatically follows the movement of mobile nodes.

This module visualizes routes in the routing tables on a 3D osg scene. It displays an arrow for each route in the routing tables of the network. The arrow points from the node containing the routing table towards the gateway. The arrow automatically follows the movement of mobile nodes.

This module integrates canvas and osg routing table visualizers into a single module.

This module visualizes a medium on a 2D canvas. It displays communication ranges and interference ranges as circles around network nodes. It displays an image at network nodes which are currently transmitting, and a different image at other network nodes whcih are currently receiving. It also displays radio signals as a 2D ring or a 3D sphere as they propagate through the medium.

This module visualizes a medium using a 3D osg scene. It displays communication ranges and interference ranges as circles around network nodes. It displays an image at network nodes which are currently transmitting, and a different image at other network nodes whcih are currently receiving. It also displays radio signals as a growing 2D ring or a 3D sphere as they propagate through the medium. All 2D shapes such as circles, rings, and images can be displayed in 4 different planes: camera, xy, xz and yz. It's also possible to use animated images.

This module integrates canvas and osg medium visualizers into a single module.

This module visualizes physical layer links on a 2D canvas. It displays an arrow for each active link in the network. See the documentation of the base module for what constitutes an active link. The arrow points from the source towards the destination. If a link is used in both directions then there are separate arrows for them. Each arrow fades out over time as the link becomes inactive unless it is reinforced by another packet. The arrow automatically follows the movement of mobile nodes.

This module visualizes physical layer links on a 3D osg scene. It displays an arrow for each active link in the network. See the documentation of the base module for what constitutes an active link. The arrow points from the source towards the destination. If a link is used in both directions then there are separate arrows for them. Each arrow fades out over time as the link becomes inactive unless it is reinforced by another packet. The arrow automatically follows the movement of mobile nodes.

This module integrates canvas and osg data link visualizers into a single module.

This module visualizes radios on a 2D canvas.

This module visualizes radios on a 3D osg scene.

This module integrates canvas and osg radio visualizers into a single module.

This module visualizes obstacle loss on a 2D canvas. It displays a line at the intersections of signal propagation paths with physical objects, and normal vectors of physical object faces at intersection points.

This module visualizes obstacle loss on a 3D osg scene. It displays a line at the intersections of signal propagation paths with physical objects, and normal vectors of physical object faces at intersection points.

This module integrates canvas and osg obstacle loss visualizers into a single module.

This module visualizes energyStorages on a 2D canvas.

This module visualizes energyStorages on a 3D osg scene.

This module integrates canvas and osg energyStorage visualizers into a single module.

This module visualizes multiple network connections on a 2D canvas.

This module visualizes multiple network connections on a 3D osg scene.

This module integrates canvas and osg connection visualizers into a single module.

This module visualizes multiple network nodes on a 2D canvas. It maintains a NetworkNodeCanvasVisualization figure for each node in the network which can be annotated by other visualizers.

This module visualizes multiple network nodes on a 3D osg scene. The visual representation is either a 3D external model or a 2D icon that is rotated automatically towards the camera. The 3D external model is specified in the osgModel module parameter of the network node. The 2D icon is the image specified in the display string of the network node. The visualizer maintains a NetworkNodeOsgVisualization instance for each network node which can be annotated by other visualizers.

This module integrates canvas and osg node visualizers into a single module.

This module visualizes the scene on a 2D canvas. It provides the 3D coordinate system's 2D projection for other visualizers. This is used to get a consistent visualization accross all visualizers. It also displays the coordinate system axes.

This module visualizes the scene using osg earth. It displays a 3D osg map of some part of the earth as an integrated part of the 3D visualization of the simulation. The map is loaded from an external resource specified by the mapFile parameter. The playground is placed on the map according to the coordinate system module.

This module visualizes the scene using osg. It displays the playground and the coordinate system axes. It sets the initial viewpoint of the 3D scene based on the bounding sphere of all network nodes. The viewpoint is located opposite of the coordinate system origin with respect to the sphere, and it faces towards the center of the sphere.

This module integrates canvas and osg scene visualizers into a single module.

This module visualizes transport layer connections on a 2D canvas. It displays a pair of colored icons for each connection at the network nodes where the connection starts or ends.

This module visualizes transport layer connections on a 3D osg scene. It displays a pair of colored icons for each connection at the network nodes where the connection starts or ends.

This module integrates canvas and osg transport connection visualizers into a single module.

This module visualizes transport layer routes on a 2D canvas. It displays an polyline arrow for each active route in the network. See the documentation of the base module for what constitutes an active route. The arrow points from the source towards the destination. If a route is used in both directions then there are separate pathes for them. Each polyline fades out over time as the route becomes inactive unless it is reinforced by another packet. The polyline automatically follows the movement of mobile nodes.

This module visualizes transport layer routes on a 3D osg scene. It displays an polyline arrow for each active route in the network. See the documentation of the base module for what constitutes an active route. The arrow points from the source towards the destination. If a route is used in both directions then there are separate pathes for them. Each polyline fades out over time as the route becomes inactive unless it is reinforced by another packet. The polyline automatically follows the movement of mobile nodes.

This module integrates canvas and osg transport route visualizers into a single module.