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

This module implements a generic sink application.

This module 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.

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

This module implements an Ethernet application that only receives packets.

This module provides Ethernet socket handling for generic applications.

This module 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.

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

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

This module implements an IEEE 802.2 LLC application that only receives packets.

This module provides IEEE 802.2 LLC socket handling for generic applications.

This module implements an IEEE 802.2 LLC application that only sends packets.

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

This module implements a IP application that only receives packets.

This module provides IP socket handling for generic applications.

This module implements a 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).

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.

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. May be used as a rough model of HTTP or FTP users. Compatible with both IPv4 (Ipv4) and IPv6 (Ipv6).

This module is a generic TCP client application. The traffic source and traffic sink modules can be built from queueing model elements.

This module provides TCP client socket handling for generic TCP applications.

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

Thread for TcpEchoApp

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

This module is 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.

This module is a generic TCP server application with a TCP server listener that creates TCP server connections.

This module is a generic TCP server connection. The traffic source and traffic sink modules can be built from queueing model elements.

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

This module accepts/rejects TCP connections and creates TCP server connections as part of a generic TCP server application.

This module provides TCP server socket handling for generic TCP 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. 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.

Models Telnet sessions with a specific user behaviour. 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.

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

This module 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 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.

This module is 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.

Consumes and prints packets received from the Udp module.

This module implements a UDP application that only receives packets.

This module provides UDP socket handling for generic applications.

This module 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 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.

This is a base module for clocks.

This is a base module for oscillators that drift relative to the nominal tick length over time.

This is a base module for oscillators.

This module interface is implemented by clock models. Clocks are typically modules, and are used by other modules via direct C++ method calls.

This module interface is implemented by oscillator models. Oscillators are typically simple modules, and are used by other modules via direct C++ method calls.

Models a clock where the clock time is identical to the simulation time.

This module contains several subclocks and also implements the clock module interface itself. It exposes the currently active clock to its users. The active clock can be changed programmatically. This module is primarily useful for multi domain gPTP time synchronization.

Models a clock which can be set to a different clock time. The clock time can be set from C++ or using a <set-clock module="..." time="..."/> command in a ScenarioManager script.

This module generates ticks periodically using a constant drift in the clock speed. The first tick is at the simulation time of the module initialization optionally shifted with an offset. The constant drift can be set from C++ or using a <set-oscillator module="..." drift-rate="..." tick-offset=".."/> command in a ScenarioManager script.

This module generates ticks periodically with a constant tick length.

This oscillator changes drift rate over time. The drift rate is the sum of a distribution that is evaluated periodically and a random walk process.

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

This module interface is implemented by 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.

This module connects multiple applications, protocols and interfaces with each other and automatically dispatches messages and packets between them. It allows many different configurations from layered architectures where message dispatchers separate different communication layers to centralized architectures where a single message dispatcher is connected to all components.

This module 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.

This module interface is used by geographic coordinate systems. A geographic coordinate system maps scene 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.

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.

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

Thruput measurement utility module.

This channels adds support for thruput 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. 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.

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.

This module provides a base module for external network interfaces.

This module provides a bidirectional connection to an ethernet 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.

This module 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 real TAP device on 'lowerLayerOut' gate.

This module 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.

This module 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.

This module 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.

This module 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.

This module 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.

This module 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 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.

This module implements a trivial MAC protocol for use in AckingWirelessInterface.

This module 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.

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

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

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

This module 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.

This module implements a generic wireless network interface.

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

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.

This module 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 GlobalArp module and completely eliminate the ARP protocol messages.

This module 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.

This module 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.

This module provides a trivial gate scheduling algorithm that makes all gates in the network to be open all the time.

This module 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 to much time of the gate cycle and thus end up failing.

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

This module interface is implemented by 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.

This module 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: EthernetCsmaMac like IEtherMac). The existing implementations are these: EthernetCsmaMac and EthernetMac.

This module interface is implemented by Ethernet network interfaces.

This module interface is implemnted by external network interfaces.

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.

This module interface is implemented by loopback network interfaces.

Interface for MAC address tables

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.

This module interface is implemnted by network interfaces.

This module interface is implemented by PPP network interfaces.

Module interface for Spanning Tree protocols

This module interface is implemnted by tunnel network interfaces.

This module interface is implemnted by virtual network interfaces.

This module interface is implemented by wired network interfaces.

This module interface is implemented by wireless network interfaces.

Module interface for CSMA/MA 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.

This module represents an Ethernet network interface.

This module implements an Ethernet network interface.

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 Ieee8022Llc and EthernetEncapsulation for that.

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

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

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

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

This module 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.

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

This module handles the mapping between ports and MAC addresses.

This module is 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.

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

This module 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.

This module represents an Ethernet network interface with cut-through support.

This module 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 the 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.

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

Implements an MPDU aggregation policy which 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.

Implements the default originator block ACK agreement policy

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

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

Implements the default originator ACK policy for QoS stations.

Implements the default RTS policy for QoS stations.

Implements the default RTS policy.

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 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 default recipient ACK policy for QoS stations.

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

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

This module implements an IEEE 802.15.4 narrowband network interface.

This module implements an IEEE 802.15.4 UWB-IR network interface.

TODO this module is incomplete

TODO this module is incomplete

This module implements the IEEE 802.1as protocol also known as gPTP. It measures link delays to neighboring gPTP network nodes periodically. The slave and master ports specify where are the connected gPTP network nodes and their roles in the time synchronization domain. The time synchronization is done periodically and the clock module is set.

This module implements a gPTP bridge network node.

This module implements a gPTP end station that contains a clock module and a gPTP protocol.

This module provide a gPTP master network node.

This module provide a gPTP slave network node.

This module 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 in to this module.

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. Shows if a network topology is loopfree, all nodes are connected or it has tree topology.

This module 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.

This module implements the IEEE 802.1Q asynchronous shaper.

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

This module implements the IEEE 802.1Q credit-based shaper.

This module 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 about the connections between the submodules based on the streamFilterTable parameter.

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

This module implements the IEEE 802.1Q time aware shaper.

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

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

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

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

This module 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.

This module 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.

This module 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.

This module 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.

This module implements the IEEE 802.1r protocol encapsulation/decapsulation.

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

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

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

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

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

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

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

This module implements a wireless network interface using the L-MAC protocol.

Loopback interface module implementation.

This module implements a loopback network interface.

PPP implementation.

This module implements a PPP network interface.

This module implements a simpistic network interface that uses a shortcut to the receiver at the MAC layer.

This module 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.

This module implements a TUN network interface.

This module implements a virtual network interface.

This module filters out packets based on the attached VlanInd tag.

This module filters out packets based on the attached VlanReq tag.

This module updates the VlanReq tag on packets.

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

This module 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 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.

This module provides a mobility that is attached to another mobility at a given offset. The position, velocity and acceleration are all affectred by the respective quantites and the orientation of the mobility where this one is attached.

Uses the native file format of 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.

This module 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 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.

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.

Implements the Random Waypoint mobility model.

Moves the node around a rectangle.

This mobility module combines the trajectory of several other mobility modules using superposition. In other words, the position, velocity and acceleration is the sum of the respective quantities of all submodules.

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.

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

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

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

This module provides global address resolution without exchanging packets.

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 serves as the base module for all network interfaces.

This module provides a simple network layer.

This module serves as a base module for layer 3 network configurators.

This module interface is implemented by all layer 3 network configurators.

This module interface is implemented by all network wide configurator modules.

HostAutoConfigurator automatically assigns IP addresses and sets up routing table. It has to be added into 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.

This module 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.

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.

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

IPv6 Tunnel Manager

This module interface provides an abstraction for 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.

ICMPv6 implementation.

Implements IPv6 Neighbour Discovery.

Delay module interface for InternetCloud.

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.

ICMP implementation.

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 Ipv4Header message class.

Stores the network address translation table.

Network 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 the IPv6 protocol.

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.

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.

This module is a simplified next hop forwarding that routes datagrams using different kind of network addresses.

This module provides a network layer for the next hop forwarding.

This module 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.

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

Table-base ingress classifier.

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

This module implements a very minimalistic link state routing protocol. 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).

This module serves as a network base module for Time-Sensitive Networking (TSN).

It models a WirelessHost extended with Aodv submodule.

This module contains the most basic infrastructure for network nodes that is not strictly communication protocol related.

IP router with BGPv4 and OSPFv4 support.

This is the module interface for all Ethernet node types in a network.

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

A DSDV router.

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

200 gigabit/sec Ethernet link

400 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 Ethernet hub model.

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.

A wireless host containing routing, mobility and energy components. Supports IPv4 network protocol, TCP, UDP, and SCTP 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.

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.

This module implements a wireless sensor node. It has one 802.15.4 wireless interface and an energy storage module by default.

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 Ieee80211Interface with mgmt.typename = Ieee80211MgmtSta added. It should be used in conjunction with AccessPoint, or any other AP model which contains Ieee80211Interface with mgmt.typename = 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 replaceable.

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.

An OSPFv3 router.

An RIPv2 router.

This module represents a hardware device containing a high precision hardware clock. The device also contains a gPTP protocol implementation and acts as a gPTP master node in the network.

This module represents a Time-Sensitive Networking (TSN) hardware end device that supports time synchronization, per-stream filtering and policing, scheduling and traffic shaping, frame replication and elimination, frame preemption for Ethernet networks. All TSN features are optional and they can be combined with other Ethernet features.

This module represents a Time-Sensitive Networking (TSN) switch that supports time synchronization, per-stream filtering and policing, scheduling and traffic shaping, frame replication and elimination, frame preemption and cut-through switching for Ethernet networks. All TSN features are optional and they can be combined with other Ethernet features.

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.

Models a generic wiring hub.

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 radio model is part of a simple hypothetical layered radio. It produces detailed transmissions that have separate representation for all simulated domains. It must be used in conjunction with the ApskLayeredDimensionalRadioMedium model.

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 radio model is part of a simple hypothetical layered radio. It produces detailed transmissions that have separate representation for all simulated domains. It must be used in conjunction with the ApskLayeredScalarRadioMedium model.

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 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 computes the antenna gain from the direction using linear interpolation. The gain parameter contains a sequence of angle [degree] and gain [dB] pairs. The first pair must be at 0 [degree].

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

Models a hypotetical antenna with a cosine-based radiation pattern. This antenna model is commonly used in the real world to approximate various directional antennas.

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

Module base for different physical layers.

This module servces as a base module for propagation models.

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

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

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

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

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.

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

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.

This module implements an IEEE 802.11 OFDM receiver. The implemenation details are based on the following standard: IEEE Std 802.11-2012 PART 11: WIRELESS LAN MAC AND PHY SPECIFICATIONS

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

See also: Ieee80211ScalarRadioMedium, Ieee80211ScalarTransmitter, Ieee80211ScalarReceiver, ScalarAnalogModel.

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 module provides a radio power consumer model for IEEE 802.11 radios. Default values are roughly based on CC3220 transceiver. The power 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 for IEEE 802.11 radios. Default values are roughly based on CC3220 transceiver. The power consumption is determined by the radio mode, the transmitter state and the receiver state using constant parameters.

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 radio model uses ideal analog representation. It must be used in conjunction with the UnitDiskRadioMedium model.

See also: Ieee80211UnitDiskTransmitter, Ieee80211UnitDiskRadio, UnitDiskRadioMedium.

See also: Ieee80211UnitDiskReceiver, Ieee80211UnitDiskRadio, UnitDiskRadioMedium.

This module implements a simple shortcut to peer radio protocol that completely bypasses the physical medium. This radio module directly sends packets to the other radio module without any physical layer processing in the radio medium. Packets received from the upper layer protocols may be lost. Physical layer overhead is simply simulated by physical header bits, preamble transmission duration and a propagation delay.

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 UnitDiskRadioMedium model.

This radio medium model provides a very simple but fast and predictable physical layer behavior. It must be used in conjunction with the UnitDiskRadio 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.

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.

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

This module takes packets streamed to its input and passes them to its output.

This module serializes packets flowing from its input to its output.

This module takes packets passed to its input and streams them to its output.

This module takes packets passed to its input and streams them to its output.

This module interface is implemented by all protocol layer modules that connect to a higher and to a lower protocol layer, both of which is optional.

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

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

This module classifies packets based on the stream they are part of. The stream is determined by a StreamReq or a StreamInd or both.

This module combines a stream decoder and a stream encoder into a layer. For incoming packets the stream decoder determines the stream of the packet. For outgoing packets the stream encoder determines the VLAN id, etc. of the packet.

This module decodes the stream of a packet by matching various tags on the packet against the mapping. It can check for network interface, source address, destination address, VLAN id, and PCP. If a match was found then the stream is attached to the packet in a StreamInd tag.

This module encodes the stream name of a packet into several request tags attached to the packet. It looks up the stream in the mapping and attaches the necessary request tags to the packet based on the specified parameters.

This module implements a packet filter using solely the stream name. The stream name must match the filter criteria in order the packet to pass through the filter.

This module identifies the stream of a packet using packet filter expressions. It can check for arbitrary packet data and assign and if a match was found then the stream is attached to the packet in a StreamReq tag.

This module wraps a stream identifier into a protocol layer so that it can be used in a layered compound module.

This module merges the packets of the same stream by removing duplicates. In addition it also replaces the stream name on the packet based on the mapping parameter. For merging it maintains a separate finite buffer per stream with the last seen sequence numbers.

This module combines a stream merger and a stream splitter module into a stream relay layer. For incoming packets the identified streams are merged by the stream merger. For outgoing packets the requested streams are split by the stream splitter.

This module duplicates incoming packets based on the stream they are part of. The stream is determined by the StreamReq tag that is attached to the packet. The number of outgoing packet is determined by the mapping parameter. Each outgoing packet will have an attached StreamReq with the tag name taken from the mapping parameter.

This module is a packet filter that operates based on the EligibilityTimeTag attached to the packet that is passing through. Packets are dropped if the tag is missing. If the maxResidenceTime parameter is set, then the filter also drops the packets for which the eligibility time in the attached EligibilityTimeTag is greater than the current simulation time plus the maximum residence time.

This module is a packet gate that operates based on the EligibilityTimeTag attached to the next packet waiting to be pulled through. The gate is closed if the eligibility time is greater than the current simulation time, it is open otherwise.

This module is a packet meter which measures the packet flow that is passing through and optionally attaches an EligibilityTimeTag to the packets. The tag contains the calculated simulation time when the packet becomes eligibile for transmission according to the asynchronous shaper algorithm.

This module is a packet queue that keeps the packets in ascending order based on the eligibility time in the attached EligibilityTimeTag of the packets.

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

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

This module receives signals from the transmission medium (wire) as a stream. It receives the signal start and signal end separately. It sends packets to the upper layer as a whole.

This module receives signals from the physical medium (wire) as a whole. It also sends up packets to the upper layer as a whole.

This module receives packets from the upper layer as a whole. It also sends signals to the transmission medium (wire) as a whole.

This module receives packets from the upper layer as a whole. It sends signals to the transmission medium (wire) as a stream, it sends the signal start and signal end separately.

This module receives signals from the transmission medium (wire) as a stream and also sends packets to the upper layer as a stream. The stream start and stream end are sent seperately allowing the preemption of signals.

This module receives packets from the upper layer as a stream and also sends signals to the transmission medium as a stream. The stream start and stream end are sent seperately allowing the preemption of signals.

This is a base module for various active packet sink modules.

This is a base module for various active packet source modules.

This is a base module for various packet buffer modules which maintains a few statistics.

This is a base module for various packet classifier modules. Derived modules must implement a single packet classifier function which determines the index of the output gate for the next pushed packet.

This is a base module for various packet filter modules. Derived modules must implement a single packet matcher function which determines if a packet is to be passed through or filtered out.

This is a base module for various packet flow modules. A packet flow module passes or streams all pushed or pulled packets after processing them from its input to its output.

This is a base module for various packet gate modules.

This is a base module for various packet labeler modules.

This is a base module for various packet marker modules. Derived modules must implement a single markPacket() function which marks the individual packets by attaching tags.

This is a base module for various packet meter modules. Derived modules must implement a single meterPacket() function which meters the flow of and attaches the required tags.

This is a base module for various packet processing modules which maintains a few statistics.

This is a base module for various packet puller modules.

This is a base module for various packet pusher modules.

This is a base module for various packet queue modules which maintains a few statistics.

This is a base module for various packet scheduler modules. Derived modules must implement a single packet scheduler function which determines the index of the input gate for the pulled packet.

This is a base module for various packet server modules.

This is a base module for various packet sink modules.

This is a base module for various packet source modules. Packets are created randomly with regard to packet length and packet data. The representation of packet data can also be configured.

This is a base module for various packet tagger modules.

This is a base module for various active packet sink modules.

This is a base module for various active packet source modules.

This is a base module for various token generator modules.

This module provides packet storage for sharing and optimizing storage space between multiple packet queues. When a packet buffer becomes overloaded, the packet dropping strategy can drop any number of packets from any number of connected packet queues.

This buffer drops packets among the connected packet queues based on their module id.

This module connects one packet producer to multiple packet consumers. It can be pushed with packets from the connected packet producer. When this happens, the classifier pushes the packet to one of its connected packet consumers based on the configured packet filters. The first matching expression determines the index of the output gate.

This packet classifier module classifies packets using two token buckets. Each packet is classified depending on which token bucket is the first one that contains the required number of tokens for the packet.

This module classifies packets based on the attached labels in a LabelsTag.

This module implements a packet classifier using a Markov process that has as many states as output gates the classifier has. The output gate for a given packet is determined by the current state of the Markov process.