Periodically synchronizes the slave clock to the master clock with the specified accuracy. The synchronization happens directly using C++ method calls and without any packet exchange. This is primarily useful when the overhead of the time synchronization protocol messages can be safely ignored.

Implements a generic sink application.

Implements a generic source application.

Generic application interface.

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 ~Ieee802SapReq tags on the packets. It generates packets containing ~EtherAppReq chunks. It should be connected directly to ~Ieee8022Llc.

Server side of the ~EtherAppClient model -- generates packets containing ~EtherAppResp chunks with the number of bytes requested by the client in corresponding ~EtherAppReq. It should be connected directly to ~Ieee8022Llc module.

Generates traffic as an Ethernet application. The traffic source and traffic sink modules can be built from queueing model elements.

Implements an Ethernet application that only receives packets.

Provides Ethernet socket handling for generic applications.

Implements an Ethernet application that only sends packets.

A simple traffic generator for the Ethernet model and the 802.11 model, and generally for any L2 model that accepts ~Ieee802SapReq tag on packets. It should be connected directly to ~Ieee8022Llc module.

Provides an external application that uses a host OS external process.

Module interface 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 chosen 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.

Generates traffic as an IEEE 802.2 LLC application. The traffic source and traffic sink modules can be built from queueing model elements.

Implements an IEEE 802.2 LLC application that only receives packets.

Provides IEEE 802.2 LLC socket handling for generic applications.

Implements an IEEE 802.2 LLC application that only sends packets.

Generates traffic for a IP application. The traffic source and traffic sink modules can be built from queueing model elements.

Implements an IP application that only receives packets.

Provides IP socket handling for generic applications.

Implements an IP application that only sends packets.

Application model for comparing the performance of various transport protocols.

Generates ping requests to several hosts (or rather, network interfaces), and calculates the packet loss and round trip times of the replies. It works exactly like 'ping' except that it is possible to specify several destination addresses as a space separated list of IP addresses or module names. (The L3AddressResolver class is used to resolve the address.) Specifying '*' allows pinging ALL configured network interfaces in the whole simulation. This is useful to check if a host can reach ALL other hosts in the network (i.e. routing tables were set up properly).

A QUIC server that reads and discards all received data.

A QUIC server that reads and discards all received data.

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.

Implements a peer application for SCTP NAT traversal. Supports both standard and rendezvous connection establishment methods to traverse NAT devices. Exchanges NAT traversal information with other peers and handles data transfer with configurable parameters. Supports multi-homing with multiple addresses.

Implements a rendezvous server for SCTP NAT traversal. Facilitates communication between peers behind NAT devices by maintaining connection information and exchanging address details between peers. Handles multi-homed connections and processes address addition notifications. Enables direct peer-to-peer communication by providing each peer with the necessary connection details of the other peer.

Implements a versatile SCTP application that can function as both client and server simultaneously. Supports sending and receiving data with configurable parameters including multi-streaming, PR-SCTP, and stream reset capabilities. Provides options for echo functionality, ordered/unordered delivery, and configurable think times between transmissions.

Server 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, to be used with ~TcpGenericServerApp.

A generic, very modular TCP client application, similar to ~TcpServerApp. The traffic source and traffic sink modules can be built from queueing model elements.

Opens a TCP connection to a given address and port and lets the module connected to its trafficIn and trafficOut gates send and receive data over that connection. When data is received on the trafficIn gate, it is forwarded on the TCP connection via the socketOut gate, and vice versa. This module simplifies the task of data exchange over a TCP connection. The TCP connection is opened when the module first receives data on its trafficIn gate.

Accepts any number of incoming TCP connections, and sends back the data that arrives on them. The echoFactor parameter controls the amount of data to be sent back. If echoFactor==1, the received data is echoed back without change. For any other positive value of echoFactor, a message of appropriate length (datalen*echoFactor) without content (see ByteCountChunk C++ class) is sent back.

Thread for ~TcpEchoApp

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

A generic request/response based server application. For each request it receives, it generates a different traffic based on the data the request contains. The client application can be any source that is capable of generating packets with different data. The first byte of the packet data determines the response traffic, which can be configured to produce complex streams of packets with various data and timing distributions.

A generic, modular TCP server application. It is composed of a listener module that listens on a port to accept TCP connections, and for each incoming TCP connection it dynamically creates a new module in the connection[] submodule vector to handle the connection.

This is a pre-assembled module type to be used in ~TcpServerApp. One instance of this module type is launched by ~TcpServerListener for each incoming connection. It is composed of a traffic source, a traffic sink, a socket I/O and other modules, and most of the module types are parametric. The traffic source and traffic sink modules can be built from queueing model elements.

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

Opens a TCP socket to listen on a port, accepts incoming connections, and dynamically creates modules to handle them. The type of modules to be created can be specified in a parameter. The new modules will be appended to the connection[] submodule array of the parent of this module, i.e., they will be siblings of this module.

Manages an established TCP connection. It handles data transmission to and from a module connected via the trafficIn and trafficOut gates. When data is received on the trafficIn gate, it is forwarded on the TCP connection via the socketOut gate, and vice versa. This module simplifies the task of data exchange over an established TCP connection.

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. Compatible with both IPv4 (~Ipv4) and IPv6 (~Ipv6).

Accepts any number of incoming TCP connections, and discards whatever arrives on them. Compatible with both ~Ipv4 and ~Ipv6.

Handles a single incoming TCP connection for ~TcpSinkApp.

Models Telnet sessions with a specific user behavior. The server app should be ~TcpGenericServerApp. Compatible with both ~Ipv4 and ~Ipv6.

This client application contains a configurable pre-composed telnet traffic source and traffic sink.

This server application accepts and creates telnet server connections.

Contains a configurable pre-composed telnet traffic source and traffic sink as part of a telnet server application.

Provides loopback functionality for a TUN interface by receiving packets, swapping source and destination addresses and ports, and sending them back through the same interface. Processes both network and transport layer headers to properly reverse packet direction. Useful for testing network configurations and protocols without requiring external connections.

Relays packets between a pre-existing tunnel endpoint (a local TUN interface) and a remote network address using either UDP or IPv4 protocols.

Generates traffic for a UDP application. The traffic source and traffic sink modules can be built from queueing model elements.

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 (~Ipv4) and IPv6 (~Ipv6).

Listens on a 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.

A generic request/response-based server application. For each request it receives, it generates different traffic based on the data the request contains. The client application can be any source that is capable of generating packets with different data. The first byte of the packet data determines the response traffic, which can be configured to produce complex streams of packets with various data and timing distributions.

Consumes and prints packets received from the ~Udp module.

Implements a UDP application that only receives packets.

Provides UDP socket handling for generic applications.

Implements a UDP application that only sends packets.

Video streaming client.

Video stream server. To be used with ~UdpVideoStreamClient.

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 talk spurt support added. Packets do not contain actual voice data. Connection setup/teardown is not modeled. The peer must be a ~SimpleVoipReceiver.

VoipStreamReceiver listens on a 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 a 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 a 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.

Base module for clocks.

Base module for clock servos.

Base module for oscillators whose effective tick rate may drift relative to a nominal tick length. This module provides the mapping used by clocks without generating one event per tick.

Base module for oscillators.

Interface for clock models.

Interface for clock servo models.

Interface for oscillator models.

Ideal clock: clock time equals simulation time.

Multi-clock aggregator and switch.

Oscillator-driven clock.

This module represents a settable (step-able) clock with adjustable oscillator compensation.

Oscillator with constant fractional frequency offset (drift).

Ideal strictly periodic oscillator (no drift).

Oscillator with time-varying drift driven by a bounded random walk.

No-op clock servo.

Step (bang-bang) clock servo.

Executes a setup command on the host OS during initialization and another teardown command during module destruction. For example, it can be used to configure virtual network interfaces.

Launches an external OS process in the background, using the command line given in the 'command' parameter. The process is terminated when the module is deleted. This module requires using the ~RealTimeScheduler class as the simulation event scheduler.

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

Interface for all standalone measurement modules. These measurement modules can be used in various places such as network interfaces, network nodes, subnetworks or even the whole network. They most often collect statistical results by subscribing to signals of other modules and by doing their calculation internally.

Module base for different layered protocols.

Facilitates the interconnection of applications, protocols, and network interfaces, dispatching messages and packets among them. It supports diverse configurations, ranging from layered architectures with distinct message dispatchers for separate communication layers, to centralized structures where a single dispatcher manages connections to all components.

Base module for all INET compound modules.

Base module for all INET modules.

Measures the residence time of packet data in network nodes. The measurement is done by tracking every bit individually using their unique identity. For each bit, the measurement starts when the incoming enclosing packet reception ends (or starts) in the network node. Similarly, for each bit, the measurement ends when the outgoing enclosing packet transmission starts (or ends) in the network node.

Base module for all INET simple modules.

Interface for geographic coordinate systems. A geographic coordinate system maps scene coordinates to geographic coordinates, and vice versa.

Provides an accurate geographic coordinate system using the built-in OSG API.

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

Keeps track of the status of the 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.

This channel uses the per parameter for periodic packet loss. That means it delivers exactly 1/per packets, followed by one drop. It does not use the BER paramater.

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

Thruput measurement utility module.

This channel adds support for throughput metering to the datarate channel. A cDatarateChannel extended with throughput calculation. Values are displayed on the link, using the connection's "t=" or "tt=" 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(1,2). The output filename is expected in the pcapFile parameter. The PcapRecorder module can also print tcpdump-like textual information on the log (EV); this functionality can be controlled by the verbose parameter.

~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 behavior.

A base for external network interfaces, network interface modules that connect the simulation to the network stack of the host OS.

Provides a bidirectional connection to an Ethernet socket of the host computer which is running the simulation. It writes the packets that arrive on upperLayerIn gate to the specified real socket and sends out packets that arrive from the real socket on the upperLayerOut gate.

Provides a bidirectional connection to a real TAP device of the host computer which is running the simulation. It writes the packets arrived on lowerLayerIn gate to the specified real TAP device, and sends out packets arrived from the real TAP device on lowerLayerOut gate.

Provides an Ethernet network interface suitable for emulation. The lower part of the network interface is realized in the real world using a real Ethernet socket of the host computer which is running the simulation.

Provides an Ethernet network interface suitable for emulation. The upper part of the network interface is realized in the real world using a real TAP device of the host computer which is running the simulation.

Provides an IEEE 802.11 network interface suitable for emulation. The upper part of the network interface is realized in the real world using a real TAP device of the host computer which is running the simulation.

Provides a bidirectional connection to an IPv4 socket of the host computer which is running the simulation. It writes the packets arrived on upperLayerIn gate to the specified real socket, and sends out packets arrived from the real socket on upperLayerOut gate.

Provides a bidirectional connection to a real TUN device of the host computer which is running the simulation. It writes the packets arrived on lowerLayerIn gate to the specified real TUN device, and sends out packets arrived from real TAP device on lowerLayerOut gate.

Provides IPv4 layer functionality for network emulation that connects the simulation to a real network on the host computer. Sends packets from the simulation to the real network and receives packets from the real network into the simulation using raw sockets. Uses ~Ipv4Encap for packet encapsulation and ~ExtIpv4Socket for the connection to the host's networking stack.

Provides a simplified network layer for emulation that connects the simulation to a real network on the host computer. Uses ~ExtLowerIpv4 to send packets from the simulation to the real network and receive packets from the real network into the simulation using raw sockets.

Provides IPv4 layer functionality for network emulation that connects simulated applications to a real network on the host computer. Uses a real TUN device on the host OS to capture and inject packets at the IP layer, allowing simulated applications to communicate with real-world network endpoints through the host's networking stack.

Provides a network layer that connects the simulation to a real network on the host computer using a TUN device. Allows simulated applications to send and receive packets through the host's networking stack at the IP layer. Contains standard components like routing table and ARP, and uses ~ExtUpperIpv4 with a TUN device for external connectivity.

Handles IPv4 encapsulation and decapsulation for network emulation. Adds IPv4 headers to outgoing packets and removes them from incoming packets. Processes packet tags for fields like TOS, DSCP, ECN, and hop limit. Supports socket operations and manages protocol registration for dispatching packets to the appropriate upper layer protocols.

Provides UDP protocol services suitable for emulation. The lower part of the UDP protocol is realized in the real world using real UDP sockets of the host computer which is running the simulation.

The propagation of communication signals, the movement of communicating agents, or battery exhaustion depends 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.

Module interface for ground models that define the terrain in physical environment simulations. Provides methods to compute ground projections and normals for any position, which is necessary for accurate modeling of signal propagation and mobility over terrain. Implementations range from simple flat surfaces to terrain models based on real-world elevation data.

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

Module interface for physical environment models that contain physical objects affecting signal propagation. Implementations define a space with objects of various shapes, positions, orientations, and materials. These objects impact wireless signal propagation through absorption, reflection, refraction, and diffraction.

Models a flat ground surface with a configurable elevation. Provides methods to compute the ground projection of a 3D position by setting its z-coordinate to the elevation value, and to compute the ground normal which is always pointing upward (0,0,1) for a flat surface.

Models a ground surface using OsgEarth's elevation data. Provides methods to compute ground projections and normals based on real-world terrain information. Requires OsgEarth integration to be enabled during compilation and depends on a SceneOsgEarthVisualizer for accessing the map and a coordinate system for geographic conversions.

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.

Extended AODV network with an additional Ethernet-connected host that can receive traffic from the wireless AODV network.

Example Ipv4 router with BGPv4 support.

Example IP router with BGPv4 and OSPFv4 support.

Diffserv Queue used in Experiment 1.1 - 1.6 and 5.1.

Diffserv Queue used in Experiment 2.1 - 2.4.

Traffic conditioner used in Experiments 1.1-1.6 and 5.1.

Traffic conditioner used in Experiment 3.1.

Traffic conditioner used in Experiment 3.2.

This network contains a router with an 10Mbps Ethernet interface, and with a 128kbps dialup connection to a server.

TODO documentation

Sample Ethernet LAN: four hosts on a bus.

A 100Mb/s Ethernet cable(1,2,3). Part of ~LargeNet(1,2).

Sample Ethernet LAN: four hosts connected by a hub.

Several hosts and an Ethernet hub on a switch. One port of the hub connect to a 10Base2 segment. Part of ~LargeNet(1,2).

A large Ethernet LAN -- see model description here.

Several hosts and an Ethernet hub on a switch; part of ~LargeNet(1,2).

Sample Ethernet LAN containing eight hosts, a switch and a bus.

Several hosts on an Ethernet hub; part of ~LargeNet(1,2).

Sample Ethernet LAN: four hosts connected to a switch.

Sample Ethernet LAN: two hosts directly connected to each other via twisted pair.

This module implements an Ethernet network node that is suitable for use in Ethernet 10BASE-T1S multidrop links. Such a multidrop link uses the Ethernet Phyisical Layer Collision Avoidance (PLCA) protocol. The protocol is defined in the IEEE 802.3cg-2019 standard.

This module contains an ~EthernetSwitch connected to a ~StandardHost and a 10BASE-T1S multidrop link with a configurable number of nodes. The switch port acts as the controller of the multidrop link. The network node type can be configured for all the nodes on the multidrop link.

This module contains a single 10BASE-T1S multidrop link with a separate controller node and a configurable number of additional nodes. The network node type can be configured for all network nodes on the multidrop link.

This hierarchical network topology contains 3 levels, 72 hosts and 27 routers.

TODO documentation

TODO Auto-generated network

A 100Mb/s Ethernet cable(1,2,3). Part of ~IPv4LargeNet.

Several hosts and an Ethernet hub on a switch. One port of the hub connect to a 10Base2 segment.

A large Ethernet LAN -- see model description

Several hosts and a router on an Ethernet hub and a switch

Several hosts on a router; part of ~IPv4LargeNet.

Definition of an IP node with a transport generator that connects to IP directly, without TCP or UDP.

TODO

TODO

TODO

Models a network with several hosts. Each host may contain one or more radios. Nodes are using adhoc routing to pass information.

This network is exactly the same as baseNetwork existing among the examples of MiXiM, but the desired number of MoBAN coordinator modules have been added. Some nodes of type BaseNode use MoBanLocal module as their mobility module. Then those nodes will be considered as WBAN nodes. Those node have a parameter named "coordinatorIndex" that determines to which WBAN (coordinator) the node belongs.

A host for demonstrating mobility models only -- it contains no protocol layers at all.

Example network to demonstrate Rsvp-TE.

Example network to demonstrate Rsvp-TE.

Example network to demonstrate Rsvp-TE.

Example network to demonstrate Rsvp-TE.

Example network to demonstrate Rsvp-TE.

A generated network with grid topology.

TODO Auto-generated network

A generated network with star topology.

Several hosts and an Ethernet hub on a switch. One port of the hub connect to a 10Base2 segment.

This is a copy of the LargeNet(1,2) Ethernet demo simulation in the INET Framework, modified to add a VoIP server and a VoIP client. It can be used to test VoIP transmission on a LAN with high background traffic.

Several hosts and an Ethernet hub on a switch

Several hosts on an Ethernet hub

Well, this models a 802.11 Access Point with a Sink.

Implements a trivial MAC protocol for use in ~AckingWirelessInterface.

Implements a highly abstracted wireless network interface (NIC) that uses 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.

Module base for different MAC protocols.

Abstract base module for MAC relay unit implementations (Ethernet switches). Provides core functionality for MAC address learning and frame forwarding in bridged Ethernet networks. Contains functionality for maintaining a MAC address table that maps addresses to ports, learning addresses from incoming frames, and forwarding frames to appropriate interfaces. It is able to handle unicast, multicast, and broadcast traffic according to standard Ethernet switching rules.

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

Implements a wireless network interface using the B-MAC protocol.

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 an 802.1d User Priority (UP) value and sets it in the Iee802Ctrl control info before sending out the packet on the "out" gate.

Implements the given module interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Classifies packets and assigns a User Priority based on the IP protocol or the transport protocol port numbers.

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

Implements a generic wireless network interface.

Provides Time-Sensitive Networking (TSN) configuration using other configurators. One is used to provide the stream redundancy (stream splitting and stream merging) configuration, the other one is used to provide the gate scheduling configuration.

Allows configuring 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.

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

Configures the forwarding database (MAC address table) of all network nodes in the network based on the automatically discovered network topology. The configurator uses the shortest path algorithm to determine the outgoing network interface for all network nodes and all destination network interfaces. The effect of this configuration is that the network can use the the ~GlobalArp module and completely eliminate the ARP protocol messages.

Provides Time-Sensitive Networking (TSN) static stream redundancy configuration. The module automatically configures all the necessary modules related to stream splitting, stream merging and stream filtering in all network nodes. The configuration parameter specifies the streams with a set of path fragments.

Interface for all layer 2 node configurators.

Serves as a basis for gate scheduling configurator modules. It provides methods for derived modules to easily extract the input parameters from the network topology and also to carry out the actual configuration of the resulting schedule. The schedule is automatically configured in all of the ~PeriodicGate submodules of all queue submodules in the network interface MAC layer submodules. Besides, the application start offsets are also configured. This allows the derived modules to focus on the implementation of the actual scheduling algorithm.

Provides a trivial gate scheduling algorithm that keeps all gates in the network open all the time.

Provides a gate scheduling algorithm that eagerly reserves time slots for the configured streams in the order of their priority (0 being the lowest). The allocation makes sure that only one gate (traffic category) is open in all network interfaces at any given moment of time. This strategy may result in wasting too much time of the gate cycle and thus end up failing.

Provides a gate scheduling configurator that uses the TSNsched tool which is available at https://github.com/ACassimiro/TSNsched. Tested revision: 3f3bf663d196ec6c03e81a1e1392d4aefd158e3e

Interface for gate scheduling configurator modules. A gate scheduling configurator is responsible for configuring all ~PeriodicGate modules of all traffic categories in all network interfaces in the network.

Provides a gate scheduling algorithm that uses the open source z3 SAT solver from Microsoft. In order to be able to use this module, the corresponding 'Z3 Gate Scheduling Configurator' feature must be enabled and the libz3-dev package must be installed.

Interface for Ethernet MAC implementations. All Ethernet MAC implementations should implement this (i.e. declared as: EthernetCsmaMacPhy like IEtherMac). The existing implementations are these: ~EthernetCsmaMacPhy and ~EthernetMacPhy.

Interface for Ethernet network interfaces.

Module interface for Ethernet protocol layer implementations. Implementations typically handle the encapsulation of higher layer packets into Ethernet frames for transmission and the decapsulation of received Ethernet frames for delivery to higher layers.

Interface for external network interfaces.

Interface for gPTP module.

Interface for both upper and lower interfaces of different link layers.

Interface for the lower interface of different link layers.

Interface for the upper interface of different link layers.

Interface for loopback network interfaces.

Interface for MAC address tables, used by MAC relay units in Ethenet switches.

This interface provides an abstraction for different MAC protocols.

Module interface for modules providing Ethernet switch functionality. These modules handle the mapping between ports and MAC addresses, and forward frames to appropriate ports.

Interface for modules that implement the Media Redundancy Protocol (MRP), specified in IEC 62439-2.

Interface for network interfaces.

Interface for PPP network interfaces.

Module interface for Spanning Tree protocols

Interface for tunnel network interfaces.

Interface for virtual network interfaces.

Interface for wired network interfaces.

Interface for wireless network interfaces.

Module interface for CSMA/CA network interfaces.

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 a network interface that is suitable for use in Ethernet 10BASE-T1S multidrop links. Such a multidrop link uses the Ethernet Phyisical Layer Collision Avoidance (PLCA) protocol. The protocol is defined in the IEEE 802.3cg-2019 standard. This network interface can be used in any network node module (e.g. ~StandardHost) that allows replacing its network interfaces. All network interfaces on the same multidrop link must use this module.

Implements the Ethernet CSMA/CD MAC protocol. It supports building both Ethernet CSMA/CD and Ethernet PLCA network interfaces.

Ethernet MAC layer. MAC performs transmission and reception of frames. See the ~IEtherMac for the Ethernet MAC layer general information. Doesn't do encapsulation/decapsulation; see ~Ieee8022Llc and ~EthernetEncapsulation for that.

Performs Ethernet II or Ethernet with LLC/SNAP encapsulation/decapsulation.

Represents an Ethernet network interface.

Ethernet MAC which supports full-duplex operation ONLY. See the ~IEtherMac for general information.

Implements the given module interface and can be used as an optional module that removes itself from the module hierarchy during initialization.

Provides various layer 2 services such as packet forwarding, interface selection, virtual LAN handling, stream handling.

Provides a layer that combines the decision for local delivery with the service of reversing the direction of an incoming packet to outgoing for packet forwarding.

Classifier that forwards Ethernet PAUSE frames to the pauseOut gate, and other frames to the defaultOut gate.

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

Queue module that gives the PAUSE frames a higher priority, and using Random Early Detection algorithm on data frames, and can be parametrized with an ~IPacketQueue for serving the data frames.

Queue module that gives the PAUSE frames a higher priority.

Combines the interface MAC address learning from incoming packets with the outgoing interface selection for outgoing packets into a single layer.

Handles the mapping between ports and MAC addresses.

Implements Ethernet switch functionality by relaying frames between different ports based on destination MAC addresses. Maintains a MAC address table that maps addresses to ports, learns addresses from incoming frames, and forwards frames appropriately. Handles unicast, multicast, and broadcast traffic according to standard Ethernet switching rules, with support for VLANs.

Part of the layer 2 architecture. It turns an incoming packet into an outgoing packet simply by removing all attached indication tags and turning some of them into an attached request tag on the packet.

Extracts the source MAC address of the packet passing through and stores the mapping from this MAC address to the incoming network interface in the MAC address table (forwarding information database).

Selects the outgoing interface for the packet passing through from the MAC address table (forwarding information database) based on the destination MAC address. The selected interface is attached to the packet in an ~InterfaceReq. The packet may be duplicated if multiple interfaces are found.

Module interface for Ethernet MAC (Media Access Control) layer implementations. Defines an interface for various MAC layer variants in the modular Ethernet architecture. Provides connection points to upper layers (e.g., LLC) and lower layers (e.g., PHY) through standardized gates.

Filters Ethernet packets based on their destination MAC address. Extracts source and destination addresses from Ethernet frames and adds them as tags for use by higher layers. Accepts packets where the destination address is the receiving interface's MAC address, the broadcast address, or a multicast address for which the interface has group membership. Drops the rest as "not addressed to us". When in promiscuous mode, accepts all packets regardless of destination address.

Inserts Ethernet MAC address fields into outgoing packets. Creates and adds the source and destination address header fields at the front of each packet. Uses the destination address from the packet's MacAddressReq tag. If the source address is unspecified in the tag, it uses the MAC address of the requested target network interface. Updates packet protocol tags to reflect the added header.

Represents an Ethernet network interface with Ethernet cut-through switching support. In contrast with store-and-forward switching, Ethernet cut-through switching can begin the transmission of the outgoing packet before the reception of the corresponding incoming packet ends. Ethernet cut-through switching can significantly reduce end-to-end delay in the network.

Implements an Ethernet network interface.

Implements an IEEE 802.11 network interface. It implements a large subset of the IEEE 802.11 standard, and may use radio models and wireless signal representations of varying levels of detail. It is also extremely configurable, and its component structure makes it easy to experiment with various details of the protocol.

Module interface for the IEEE 802.11 MAC module type.

An LLC implementation that encapsulates packets with the IEEE 802 EtherType Protocol Discrimination (EPD) header, as defined in section 9.2 EtherTypes of the IEEE Std 802-2014 standard. See ~Ieee802EpdHeader.

An LLC implementation that encapsulates packets in an LLC header, using IEEE 802 LPD-style encoding.

Module interface for IEEE 802.11 Logical Link Control (LLC) implementations. LLC defines the interface between the MAC layer and network layer in IEEE 802.11 networks. Implementations handle encapsulation and decapsulation of packets, using either EtherType Protocol Discrimination (EPD) or Link Protocol Discrimination (LPD) methods.

Implements the DS (Distribution Service) for IEEE 802.11, which is responsible for distributing correctly received frames to the higher layer, to the wireless LAN, etc.

Implementation of the 802.11 MAC protocol. This module is intended to be used in combination with the ~Ieee80211Radio module as the physical layer.

Responsible for checking frames received over the radio for errors, for managing the NAV, and for notifying other processes about the channel state (free or busy).

Responsible for unconditionally transmitting a frame after waiting for a specified inter-frame space. This is the default implementation of the ~ITx module interface.

Implements an MPDU aggregation policy that never aggregates frames.

Implements a basic MSDU aggregation policy, controlled by parameters such as the minimum number of subframes needed to compose an A-MSDU, the minimum length for the aggregated payload, the maximum A-MSDU size, etc.

Manages Block Acknowledgment (Block Ack) agreements for the originator side in IEEE 802.11 networks. Handles the creation, maintenance, and termination of Block Ack agreements with receivers. Processes ADDBA requests/responses and DELBA frames, tracks agreement timeouts, and maintains the state of active agreements. Enables efficient acknowledgment of multiple frames with a single Block Ack frame.

Implements the default originator block ACK agreement policy

Manages Block Acknowledgment (Block Ack) agreements for the recipient side in IEEE 802.11 networks. Processes ADDBA requests from originators, creates and maintains Block Ack agreements, handles timeouts, and generates appropriate responses. Implements the recipient side of the Block Ack mechanism as defined in the IEEE 802.11 standard for efficient acknowledgment of multiple frames.

Implements the default recipient block ACK agreement policy.

Implements the DCAF (Distributed Channel Access Function) for IEEE 802.11.

Implements EDCA (Enhanced Distributed Channel Access) for IEEE 802.11. The implementation allows for a configurable number of access categories, not just four as defined by the standard.

Implements EDCAF (Enhanced Distributed Channel Access Function) for IEEE 802.11. EDCAF represents one access category within EDCA.

Implements HCCA (Hybrid Coordination Function Controlled Channel Access) for IEEE 802.11.

The default implementation of IContention.

A collision controller used with EDCA. It detects and reports internal collisions among ~Edcaf instances.

Interface for collision controllers. A collision controller is used with EDCA, and it detects and reports internal collisions among ~Edcaf 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 transmitting the frame, and defers when a busy channel is sensed. After receiving a corrupted frame, EIFS is used instead of the original DIFS (AIFS).

Interface for CTS policies.

Interface for modules that implement the DCF (Distributed Coordination Function) for IEEE 802.11.

Interface for modules that implement the frame Distribution Service for IEEE 802.11. The job of the Distribution Service is deciding what to do with correctly received frames. They may be discarded (e.g. on address mismatch), sent up to higher layers, and/or transmitted back on the wireless LAN after switching addresses.

Interface for fragmentation policies.

Interface for modules that implement the HCF (Hybrid Coordination Function) for IEEE 802.11.

Interface for MPDU aggregation policies.

Interface for MSDU aggregation policies.

Interface for originator ACK policies. This policy tells whether an ACK is expected for a transmitted frame, and also determines the ACK timeout.

Interface for originator Block ACK agreement policies.

Interface for the originator QoS ACK policies.

Interface for auto rate control modules.

Interface for frame rate selection modules. Rate selection decides what bit rate (or MCS) should be used for frames of various types, such as control frames, management frames, and data frames.

Interface for recipient ACK policies. This policy chooses between no ACK, normal ACK, and Block ACK for received frames.

Interface for recipient Block ACK agreement policies.

Interface for recipient QoS ACK policies.

Interface for RTS policies.

Interface for Rx processes. The Rx process checks received frames for errors, manages the NAV, and notifies other 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 upper layers, corrupted frames are discarded.

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.

Implements the DCF (Distributed Coordination Function) for IEEE 802.11.

Implements the HCF (Hybrid Coordination Function) for IEEE 802.11.

IEEE 802.11 Mesh Coordination Function

IEEE 802.11 Point Coordination Function

Implements a basic fragmentation policy, which employs a fragmentation frame size threshold.

Manages acknowledgment (ACK) status tracking for transmitted frames in IEEE 802.11 networks. Maintains a record of frame transmission states, processes received ACK frames, and determines when frames need retransmission.

Implements frame retransmission and recovery procedures for non-QoS frames in IEEE 802.11 networks. Manages short and long retry counters, adjusts contention window size based on transmission outcomes, and enforces retry limits. Handles different retry procedures for frames below and above the RTS threshold as specified in IEEE 802.11 standard section 9.19.2.6.

Implements the default originator ACK policy for non-QoS stations.

Implements the MAC data service for the originator (sender) side in non-QoS IEEE 802.11 networks. Processes outgoing frames by assigning sequence numbers and performing fragmentation based on the configured policy. Follows the MAC data plane architecture described in IEEE 802.11 standard to prepare frames for transmission.

Implements the default originator ACK policy for QoS stations.

Implements the MAC data service for the originator (sender) side in IEEE 802.11 QoS networks. Extends the basic MAC data service with QoS capabilities including MSDU aggregation (A-MSDU) and MPDU aggregation (A-MPDU). Processes outgoing frames by assigning sequence numbers, performing aggregation, and fragmentation based on configured policies. Follows the MAC data plane architecture described in IEEE 802.11 standard.

Manages acknowledgment handling for QoS frames in IEEE 802.11 networks. Tracks the status of transmitted frames, processes received acknowledgments (both normal ACKs and Block ACKs), and handles different acknowledgment policies. Supports QoS-specific features including Traffic Identifier (TID) based frame tracking and Block ACK mechanisms, enabling reliable frame delivery with Quality of Service guarantees.

Implements frame retransmission and recovery procedures for QoS frames in IEEE 802.11 networks. Manages retry counters for failed transmissions, adjusts contention window size, and enforces retry limits. Maintains separate short and long retry counters based on frame size relative to RTS threshold, and tracks per-TID frame status to support Quality of Service requirements.

Implements the default RTS policy for QoS stations.

Implements the default RTS policy.

Implements the Transmission Opportunity (TXOP) mechanism in IEEE 802.11 QoS networks. Manages TXOP periods during which a station has the right to transmit. Tracks TXOP limits based on access category (AC) and PHY mode. Supports both single and multiple protection mechanisms to protect frame exchanges during the TXOP.

Calculates the Duration/ID field for IEEE 802.11 frames to implement the Network(1,2,3,4) Allocation Vector (NAV) mechanism for virtual carrier sensing. This module computes appropriate duration values for different frame types (RTS, data, management) based on IEEE 802.11 standard rules. For RTS frames, it calculates time needed for the complete RTS-CTS-DATA-ACK exchange.

Implements the single protection mechanism for IEEE 802.11 networks as defined in the standard section 8.2.5.2. This module calculates the Duration/ID field values for different frame types (RTS, CTS, BlockAckReq, BlockAck, data, management) to properly set the Network(1,2,3,4) Allocation Vector (NAV) in receiving stations.

Implements a prioritized queue system for IEEE 802.11 MAC frames. Uses a classifier to separate incoming packets into three queues: management frames (highest priority), multicast frames (medium priority), and unicast frames (lowest priority). A priority scheduler then selects packets from these queues in order of priority.

Implements a priority queue for IEEE 802.11 MAC frames. Uses a comparator to determine the order in which frames are processed. By default, prioritizes management frames over data frames, but can be configured to use different prioritization schemes such as management over multicast over unicast frames.

Implements the Adaptive ARF (AARF) rate control mechanism, which was initially described in IEEE 802.11 Rate Adaptation: A Practical Approach, by M. Lacage, M.H. Manshaei, and T. Turletti, 2004.

Implements the Auto Rate Fallback (ARF) adaptive rate control mechanism.

Implements ONOE, a credit-based rate control algorithm originally developed by Atheros.

Implements rate selection for IEEE 802.11 QoS frames. Selects appropriate transmission rates for different frame types (data, management, control, response) based on configured parameters and dynamic conditions. Supports different bitrates for multicast frames, response frames (ACK, CTS, BlockAck), and can use a rate control module for dynamic rate adaptation.

Implements the default rate selection algorithm. Rate selection decides what bit rate (or MCS) should be used for control frames, management frames and data frames.

Implements the default CTS policy.

Implements the default CTS policy for QoS stations.

Implements the default recipient ACK policy.

Implements the MAC data service for the recipient side in non-QoS IEEE 802.11 networks. Processes received frames by performing defragmentation and duplicate detection.

Implements the default recipient ACK policy for QoS stations.

Implements the QoS MAC data service for the recipient side in IEEE 802.11 networks. Extends the basic recipient MAC data service with QoS capabilities including A-MPDU deaggregation, A-MSDU deaggregation, and block ACK reordering. Processes received frames according to the MAC data plane architecture described in the IEEE 802.11 standard.

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

IEEE 802.11 management module used for ad-hoc mode. This implementation never sends control or management frames, and discards any such frame received. Distributed beacon generation is not modeled.

Used in 802.11 infrastructure mode in an access point (AP).

Used in 802.11 infrastructure mode in an access point (AP).

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

Used in 802.11 infrastructure mode for a station (STA).

Module interface for IEEE 802.11 agent modules that provide the decision logic for selecting access points and managing wireless connections in wireless stations. Agents initiate channel scanning, association, authentication, and handovers by sending commands to the management module.

Module interface 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 ~Ieee80211Interface.

Management Information Base for IEEE 802.11 networks. Stores configuration and state information including network mode (infrastructure, ad-hoc, mesh), station type (access point or station), authentication and association status, and BSS data (SSID, BSSID). Used by various IEEE 802.11 modules to maintain protocol state and control frame addressing.

Implements the portal functionality in IEEE 802.11 networks, serving as a bridge between wireless LANs and wired networks. Performs protocol conversion between IEEE 802.11 frames and IEEE 802.3 (Ethernet) frames, handling frame format differences and LLC header management.

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

Implements an IEEE 802.15.4 narrowband network interface.

Implements an IEEE 802.15.4 UWB-IR network interface.

TODO this module is incomplete

TODO: this module is incomplete

Module interface for IEEE 802.1AE (MACsec) tag header inserters. Implementations process outgoing frames to add IEEE 802.1AE security tags with EtherType Protocol Discrimination (EPD), encapsulate packet data in encrypted chunks, and add security parameters including Secure Channel Identifier (SCI) and packet number (PN) as defined in the IEEE 802.1AE standard for MAC security.

Implements the generalized Precision Time Protocol (gPTP) as defined in the IEEE 802.1AS-2020 standard.

Implements a gPTP bridge network node.

Implements a gPTP end station that contains a clock module and a gPTP protocol.

Provides a gPTP master network node.

Provides a gPTP slave network node.

Combines multiple ~Gptp modules, one per time domain into a multi time domain time synchronization module. Each gPTP time domain is automatically configured to use the corresponding subclock of the clock passed into this module.

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 manually enabling/disabling these backup links.

Network(1,2,3,4) tester module. Shows if a network topology is loop-free, all nodes are connected, or it has a tree topology.

Implements a filtering module for the asynchronous traffic shaper taking scheduler groups into account.

Combines two meters and their corresponding filters per path. This is primarily useful for combining a token bucket based metering with an asynchronous packet shaper. Note that the asynchronous packet shaper also has parts in the network interface queue module.

Implements the IEEE 802.1Q asynchronous shaper. An alias for the EligibilityTimeGate module.

A packet gate that can be used to implement the IEEE 802.1q credit-based shaper algorithm in combination with a packet queue.

Implements the IEEE 802.1Q credit-based shaper.

Implements the IEEE 802.1Q per-stream filtering and policing. The relationship between streams, gates, and meters is not one-to-one. The number of streams, gates, and meters can be different, and the module will take care of the connections between the submodules based on the streamFilterTable parameter.

Implements IEEE 802.1Q protocol functionality as a layered architecture with policy and protocol components. The policy submodule handles VLAN filtering and mapping, while the protocol submodule manages tag encapsulation/ decapsulation. Supports both C-VLAN (0x8100) and S-VLAN (0x88A8) tag types through configuration. Enables network segmentation and traffic control in Ethernet networks by processing VLAN tags according to configured policies.

Implements the IEEE 802.1Q protocol encapsulation/decapsulation. It also provides socket support so applications can use the protocol directly.

Processes IEEE 802.1Q socket commands from applications and manages socket registrations in the socket table. Handles bind, close, and destroy commands for IEEE 802.1Q sockets, enabling applications to send and receive VLAN-tagged frames. Supports filtering traffic based on protocol and VLAN ID, providing a socket-based interface to the IEEE 802.1Q layer. Works in conjunction with ~Ieee8021qSocketTable to maintain socket state and ~Ieee8021qSocketPacketProcessor to deliver packets to the appropriate applications.

Processes packets related to IEEE 802.1Q VLAN sockets. Delivers packets to registered sockets based on protocol and VLAN ID matching. Duplicates packets for delivery to interested sockets and supports "stealing" packets to prevent them from being forwarded. Enables applications to communicate directly with specific VLANs and implements protocol handlers for VLAN-specific traffic. Works in conjunction with ~Ieee8021qSocketTable to provide a socket-based API for VLAN communication.

Maintains a table of IEEE 802.1Q VLAN sockets. Each socket entry contains a socket ID, protocol, VLAN ID, and a flag indicating whether to steal packets. The module provides functionality to add, remove, and find sockets based on protocol and VLAN ID criteria. It enables applications to communicate through specific VLANs by associating sockets with VLAN tags, facilitating the routing of packets to the appropriate protocol handlers.

Implements the IEEE 802.1Q time aware shaper.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Implements the module given by the interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialize.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Classifies packets based on the attached PCP value [0, 7]. The PCP is determined by a PcpReq or a PcpInd or both. The output gate index is the ith value in the pcpToGateIndex parameter.

Classifies packets based on the attached PCP value [0, 7]. The PCP is determined by a PcpReq or a PcpInd or both. The output gate index is the value found in the mapping matrix using the PCP value as the row index and the number of connected consumers (traffic categories) as the column index.

Implements a simplified version of the IEEE 802.1Q per-stream filtering and policing. Each filtered stream has its own path where metering and filtering happens independently of any other stream.

Combines two packet filters into a protocol layer so that it can be used in a layered compound module. There are separate submodules for ingress and egress traffic, but in most cases only the ingress filter is used.

Implements the IEEE 802.1r protocol encapsulation/decapsulation.

Implements the given module interface and can be used as an optional module that removes itself from the module hierarchy during initialization.

Implements the given module interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialize.

Implements the module given an interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

Implements the module given interface and can be used as an omitted optional module that removes itself from the module hierarchy during initialization.

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

Implements a wireless network interface using the L-MAC protocol.

Loopback interface module implementation.

Implements a loopback network interface.

Implements the Media Redundancy Protocol (MRP) as specified in IEC 62439-2. MRP is used for managing redundancy in ring network topologies commonly found in industrial network settings. MRP is similar in its function to STP and RSTP, in that it ensures a loop-free topology for an Ethernet local area network. This module implements the Media Redundancy Manager (MRM), Media Redundancy Client (MRC), and Media Redundancy Automanager (MRA) roles. This model also includes support for detecting link errors with the help of Continuity Check Messages (CCM) messages defined in 802.1q CFM.

Implements ring interconnection support for the Media Redundancy Protocol (MRP) as specified in IEC 62439-2. This is an extension of the ~Mrp module with the Media Redundancy Interconnection Manager (MIM) and Media Redundancy Interconnection Client (MIC) roles. This module should be used instead of ~Mrp in MRP nodes that are also ring interconnection nodes.

This is a variant of ~MacForwardingTable, with added support for the Media Redundancy Protocol (MRP) defined in IEC 62439-2.

Relay unit with support for the Media Redundancy Protocol (MRP), defined in IEC 62439-2.

PPP implementation.

Implements a PPP network interface.

Implements a simplistic network interface that uses a shortcut to the receiver at the MAC layer.

Implements a simple shortcut to peer MAC protocol that completely bypasses the physical layer. Packets received from the upper layer protocols are never lost. The MAC protocol directly sends packets to the destination MAC protocol without any physical layer processing. Physical layer overhead is simply simulated by overhead bits, overhead transmission duration and a propagation delay.

Implements a TUN (network tunnel) interface that provides a virtual network interface for applications. This is the main component of ~TunInterface. Allows applications to send and receive packets directly to/from the network layer using a socket-like API. Maintains a list of registered sockets and handles commands for opening, closing, and using the TUN interface. Processes packets between upper layers and the network layer, adding appropriate tags for routing.

Implements a (simulated) TUN network interface.

Implements a virtual network interface.

Creates a virtual network interface that tunnels traffic through an existing real network interface. This is the main component of ~VirtualInterface. Supports tunneling via Ethernet or IEEE 802.1Q protocols, with optional VLAN tagging for traffic separation.

Filters out packets based on the attached VlanInd tag.

Filters out packets based on the attached VlanReq tag.

Updates the VlanReq tag on packets.

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

Implements a wireless network interface using the X-MAC protocol.

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 posture specification file, a configuration file which includes all required parameters 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 determines 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 is the current posture, the sphere radius, and the speed is given by the corresponding coordinator. RWMM determines the location of a node at any time relative to the given reference point.

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

Provides a mobility that is attached to another mobility at a given offset. The position, velocity, and acceleration are all affected by the respective quantities and the orientation of the mobility where this one is attached.

Uses the native file format of the BonnMotion tool.

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.

Provides orientation towards the target mobility model as seen from the source mobility model.

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 in linear motion.

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

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

Implements the Random Waypoint mobility model.

Moves the node around a rectangle.

Combines the trajectory of several other mobility modules using superposition. In other words, the position, velocity, and acceleration are the sum of the respective quantities of all submodules.

Moves a tractor through a field with a certain number of rows. Since the tractor also moves around the field, the tractor travels the number of rows PLUS one row. 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.

Mobility model for ground vehicles that follow waypoints with realistic turning behavior. Reads waypoints from a file and moves the vehicle along them at a specified speed, calculating appropriate angular velocity for turns. Supports terrain following by projecting positions onto the ground and orienting the vehicle according to the ground normal.

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 a separationX, separationY size). Hosts are placed in the middle of each cell. By default, the number of columns and rows follows the aspect ratio of the usable area. By default, stepX and stepY are calculated based on the number of columns and rows.

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

Mobility module for stationary nodes.

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

Provides global address resolution without exchanging packets.

Module base for different network protocols.

Provides a mechanism to test network layer connectivity using echo request/response messages similar to those of ICMP.

Keeps the table of network interfaces.

Serves as the base module for all network interfaces.

Provides a simple network layer.

Serves as a base module for layer 3 network configurators.

Interface for all layer 3 network configurators.

Interface for all network-wide configurator modules.

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

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.

Assigns IPv4 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.

Configures the containing network node using information provided by the network's global configurator modue ~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.

Adds routes to a ~NextHopRoutingTable similarly to how ~Ipv4NetworkConfigurator adds static routes to the ~Ipv4RoutingTable.

Interface for Address Resolution Protocol (ARP) implementations. Provides address resolution services for mapping network layer addresses (e.g., IPv4) to link layer addresses (e.g., MAC). Modules implementing this interface maintain a cache of address mappings and handle resolution requests from the network layer.

IPv6 Tunnel Manager

Interface for different network layers.

This interface provides an abstraction for different network protocols.

Interface for different routing tables.

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

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

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.

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.

Implements a Single Rate Three Color Meter (RFC 2697).

Simple token bucket meter.

Implements a Two Rate Three Color Meter (RFC 2698).

A simple flooding protocol for network-level broadcast.

ICMPv6 implementation.

Implements IPv6 Neighbor Discovery.

Delay module interface for InternetCloud.

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

ICMP implementation.

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

Module interface for IPv4 protocol implementations. Defines gates and parameters for modules that provide IPv4 protocol functionality. The IPv4 protocol provides datagram routing, fragmentation, and addressing between network interfaces and transport layer protocols.

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

Stores the network address translation table.

Network(1,2,3,4) layer of an IPv4 node.

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

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.

Represents an IPv6 network layer (L3).

IPv6 Routing Table and Neighbor Discovery data structures. NOTE: This component MUST be named as routingTable6 inside a ~StandardHost/~Router(1,2) etc. in order to be accessible by the ~Ipv6 and other modules

IPv6 Tunnel Manager

Handles and processes LDP messages.

Module interface for ingress packet classifiers for MPLS.

Stores the LIB (Label Information Base), accessed by ~Mpls and its associated control protocols (~RsvpTe, ~Ldp) via direct C++ method calls.

Implements the MPLS protocol.

A simplified next hop forwarding that routes datagrams using different kinds of network addresses.

Provides a network layer for the next hop forwarding.

Stores next hop routes used by the next hop forwarding protocol.

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