Receives alert messages sent by nodes running an AlertSender application. It listens for incoming packets and logs their arrival. It records end-to-end delay statistics. The module also supports multicast by joining local multicast groups.

Generates periodic alert messages and sends them to a specified multicast group or unicast destination. The packet size, transmission period, start time, and stop time are configurable using the corresponding parameters. The destination address must be a multicast IP address. This module can be used in simulations that require periodic alert generation via device-to-device (D2D) communications, such as vehicular networks.

Models an application that receives bursts of packets from a BurstSender application module. It binds to a specified UDP local port, logs the received packets, and records statistics such as packet delay.

Models an application that sends bursts of packets to a BurstReceiver application. During each burst, the application sends a configurable number of packets at regular intervals. The time interval between bursts can also be configured.

Receives Constant Bit Rate (CBR) traffic sent by a CbrSender application module. It binds to a specified local port and records statistics such as packet delay, jitter, packet loss, throughput, and the total amount of bytes received.

Simple module for generating Constant Bit Rate (CBR) traffic. This module periodically sends packets of a specified size to a designated address and port. The intervals between packets and the overall duration of the communication are configurable. The module emits statistics related to the generated throughput and the total amount of bytes sent.

Disseminates event notifications using multihop D2D transmissions. New messages are generated upon the reception of external events, signaled by the EventGenerator module. The application sends the message to an IP multicast address, which is then mapped to D2D multicast transmission mode within the LTE/NR protocol stack. When the application receives a message, it can relay it to the same IP multicast address in order to extend the coverage of the D2D transmission. To avoid flooding, two mechanisms can be used:

Only used in conjunction with UEs running a MultihopD2D application instance. It generates periodic "events" (e.g., a collision between vehicles) at random positions within the network (or by randomly selecting a node) and notifies a MultihopD2D application via a direct method call. The MultihopD2D application, in turn, broadcasts the notification message to surrounding UEs.

Only used in conjunction with UEs running instances of the MultihopD2D application. It collects statistics related to notification messages broadcast by the MultihopD2D applications by gathering data through method calls from these applications.

Models the Device App entity as defined by the ETSI Multi-access Edge Computing (MEC) specifications. The Device App can be instantiated on a User Equipment (UE) that wants to dynamically instantiate a MEC application within a MEC system. It establishes a TCP connection with the User App Lifecycle Management Proxy (UALCMP) entity (see the Ualcmp module) and, upon receiving a MEC application instantiation request from another UE application, it sends a message to the UALCMP including the URI of the MEC application to be instantiated. Once the confirmation of successful instantiation is received, the Device App sends an acknowledgment to the UE application that requested it. Moreover, this module is responsible for requesting the deletion of the MEC application from the MEC system upon explicit request from the UE application.

This is a MEC app that ... TBC

This is an empty MEC app which is used as a model for MEC apps that should be shared among multiple UEs. Any shared MEC app that should extend this app

Generates requests to be sent to the LocationService. This application can be instantiated as an "independent MEC app" (see MecHost module), which means it does not need to be instantiated via the MEC orchestrator upon request from a User Equipment. In particular, this module produces bulks of GET requests, as generated by a configurable number of MEC applications running on the MEC host. The result of such requests is to delay the service of real requests (i.e., those originating from complete MEC applications)

Generates requests to be sent to the LocationService. This application can be instantiated as an "independent MEC app" (see MecHost module), meaning it does not need to be instantiated via the MEC orchestrator upon request from a User Equipment. Specifically, this module produces batches of GET requests, as generated by a configurable number of MEC applications running on the MEC host. The effect of such requests is to delay the service of actual requests (i.e., those originating from complete MEC applications)

Implements a MEC application that issues GET requests to the LocationService every 500ms. This application can be utilized as an "independent MEC app" (see MecHost module), hence it does not require instantiation via the MEC orchestrator upon request from a User Equipment. Essentially, this application provides a quick way to generate configurable load to the Location Service and simulate different (and potentially more realistic) response times from the latter.

Represents an application that is dynamically instantiated on a MEC host upon request from a UeRequestApp, via a DeviceApp. Upon receiving a request from the UE, it queries the LocationService to obtain some information (which is not utilized; it is intended only to "consume" some time), and sends a response message to the UE after a computation time that depends on the current resource utilization at the MEC host.

This application is to be instantiated on the UE side. It requires that a DeviceApp is also instantiated at the UE. This module requests the DeviceApp to instantiate a MecResponseApp in the MEC system. Once the peer MEC application is up and running, this module sends periodic messages to the MEC application and waits for a response. It collects metrics such as round-trip time.

Application that is dynamically instantiated on a MEC host upon request from a RtVideoStreamingSender application via a DeviceApp. It receives video frames sent by the UE and simulates a playout buffer. Moreover, it records statistics related to the quality of the received video stream. Note that the statistics are collected by the RtVideoStreamingSender application at the UE side.

This application is to be instantiated on the UE side. It requires that a DeviceApp is also instantiated on the UE. This module requests the DeviceApp to instantiate a MecRTVideoStreamingReceiver in the MEC system. Once the peer MEC application is up and running, this module starts sending packets containing video frames as read from the trace file specified in the configuration.

Application that is dynamically instantiated on a MEC host upon request from a UeRnisTestApp via a DeviceApp. It is used to test and showcase the functionalities of the RniService API. Upon receiving a request from the UE, it queries the RniService periodically to obtain L2 measurements related to the UE that sent the request (refer to the sendQuery() function). The results obtained from the RNIS are sent back to the UeRnisTestApp in a response message. Please note that the response time of the RNIS depends on the current load at the RNIS.

This application is to be instantiated on the UE side. It requires that a DeviceApp is also instantiated on the UE. This module requests the DeviceApp to instantiate a MecRnisTestApp in the MEC system. The application is used to test and showcase the functionalities of the RniService API. Once the peer MEC application is up and running, this module sends a message to the MEC application, requesting it to start querying the RNIS API periodically. When the response from the MecRnisTestApp is received, the result of the query to the RNIS API is printed to the QtEnv log

Application that is dynamically instantiated on a MEC host upon request from a UeWarningAlertApp via a DeviceApp. It receives requests from the UE to be notified when it enters a circular area defined by its center and radius. This is accomplished by subscribing to the LocationService provided by the MEC Host. This module receives a notification from the Location Service when the UE enters/exits the area and, in turn, sends a message to the UE.

This application is to be instantiated on the UE side. It requires that a DeviceApp is also instantiated on the UE. This module requests the DeviceApp to instantiate a MecWarningAlertApp in the MEC system. Once the peer MEC application is up and running, this module sends a message to the MEC application, requesting that it be notified when the UE running this module enters a circular area defined by its (configurable) center and radius.

Simulates a video-on-demand (VoD) client application that receives video frames over UDP. It is assumed that the transmitted video is encoded using multiple layers according to the Scalable Video Coding (SVC) technique. Hence, the module collects separate statistics (such as throughput and delay) for each layer.

Models the transmission of a video-on-demand (VoD) stream over UDP. The input is taken from a specified trace file, representing a video encoded according to the Scalable Video Coding (SVC) standard. Each line of the trace file defines the size and transmission time of a video frame.

Represents a model for the receiver of Voice-over-IP (VoIP) traffic. It receives packets sent by a VoipSender application via UDP and records statistics such as packet loss, end-to-end latency, jitter, and throughput. Furthermore, it computes and emits a MOS (Mean Opinion Score) value, which represents the Quality-of-Experience of the end users.

Represents a model for the sender of Voice-over-IP (VoIP) traffic. It generates packets by alternating "talk spurts" and "silence" periods, with their respective durations modeled by a Weibull distribution. During talk spurts, fixed-size packets are generated periodically and sent over UDP to a specified destination address and port.

Configures the channel parameters associated with a BackgroundCell. It is used to compute the channel quality for background UEs (refer to the BackgroundUe module), which in turn is essential for deriving the correct allocation of time-frequency resources via the Adaptive Modulation and Coding mechanism.

Manages the background traffic generated by BackgroundUe in a BackgroundCell.

Computes the allocation of time-frequency resources for background UEs in a BackgroundCell, taking into account the traffic generated by these UEs and their channel quality.

Part of a BackgroundCell module and is responsible for instantiating a configurable number of background UEs (see BackgroundUe module) and setting up their method for computing the channel status information required by the BackgroundScheduler module.

Manages the background traffic generated by BackgroundUe in a eNodeB or gNodeB.

This is the base module for the traffic manager for background UEs

Lightweight model for 4G or 5G User Equipment (UE). It is used to simulate the generation of background traffic in both uplink and downlink bandwidths, according to the logic specified by its ITrafficGenerator submodule. The generated traffic is not actually transmitted or received by this module, making it more efficient from a simulation complexity perspective. Instead, such traffic modifies the buffer status information that is used by the BackgroundScheduler to allocate resources. Each background UE has a mobility submodule to configure its position in the simulation floor plan. This allows for realistic channel status information to be computed for the background UE and used by the BackgroundScheduler. Since this module does not send or receive actual traffic, application-level statistics are not produced.

Defines the contract for a traffic generator manager within the BackgroundTrafficGenerator module of a eNodeB or gNodeB. This interface can be implemented by other modules to create a custom traffic generator manager; see BackgroundTrafficManager.

Defines the contract for traffic generator modules within the BackgroundTrafficGenerator module. This interface can be implemented by other modules to create a custom traffic generator; see TrafficGeneratorCbr as an example.

Provides the basic functions and parameters that a traffic generator submodule (implementing the ITrafficGenerator interface) can utilize. It enables the configuration of parameters such as the starting time of the traffic, the size and inter-generation timing of packets, the rate of retransmissions, and so on. Custom background traffic generators can be implemented by extending this module.

Specializes the TrafficGeneratorBase module to provide a Constant Bit Rate (CBR) background traffic generator. This generator produces fixed-size packets at regular intervals in either downlink or uplink bands, or both.

The Binder module functions as a global repository of network-related information utilized throughout the simulation for various control-plane functionalities. It provides a centralized storage and access point for data such as network configurations and operational parameters.

Implements the Carrier Aggregation (CA) functionality used at the Medium Access Control (MAC) layer of e/gNodeBs and UEs. CA allows multiple frequency bands - referred to as Component Carriers (CCs) - to be aggregated in order to increase the overall available bandwidth of the system. Each CC is implemented as a submodule and can be configured independently from each other. e/gNodeB and UE can be configured to use one or more CCs among those configured in this module. There must be one (and only one) instance of this module in the network.

Serves as a descriptor for one Component Carrier (CC) of a Carrier Aggregation (CA)-enabled 4G/5G network. The module is assigned a carrier frequency (which also acts as a unique identifier for the CC in the system), a bandwidth, and a numerology index (in the range of 0 to 4). It can be configured with either Frequency Division Duplex (FDD) or Time Division Duplex (TDD) mode. In the latter case, the number of uplink and downlink symbols per slot can be specified (the sum of uplink and downlink symbols must be less than or equal to 14, which is the total number of symbols in one slot).

Includes data structures and functions used to support local operations at the e/gNodeB, such as the cell ID, the set of Component Carriers (CCs) supported by the e/gNodeB, and more.

Central configurator of the network's data radio bearers.

Implements a simplified version of the user plane of the GPRS Tunneling Protocol (GTP). On one hand, this module encapsulates incoming IP datagrams into GTP packets and sends them to the tunnel destination endpoint (GTP operates on top of UDP). The destination endpoint is identified by utilizing information from the TrafficFlowFilter module. On the other hand, when this module receives GTP packets from a tunnel source endpoint, it decapsulates the included IP datagram and sends it to the intended destination according to normal IP forwarding. Used by all entities that need to communicate within the cellular core network, such as eNodeB, gNodeB, PgwStandard, Upf, and MecHost modules.

Implements a simplified version of the user plane of the GPRS Tunneling Protocol (GTP) used for handover procedures. In particular, it is employed to transfer data packets from the source e/gNodeB to the target e/gNodeB during a handover (i.e., packets destined for a UE that is undergoing a handover). On one hand, this module encapsulates incoming IP datagrams from the local LteX2Manager into GTP packets and sends them over the X2 interface. On the other hand, it receives GTP packets from other e/gNodeBs and decapsulates the included IP datagrams, which are then forwarded to the local LteX2Manager.

Collects the radio network information of an eNodeB, which can be accessed by the RniService module of a MecHost. For example, this module provides information such as the utilization of Resource Blocks.

Collects the radio network information from a 5G gNodeB, which can be accessed by the RniService module of a MecHost. Currently, it exposes the same information as the BaseStationStatsCollector module.

A module implementing this interface is a utility module that is accessed by the RniService of a MecHost module to retrieve radio network information related to the parent e/gNodeB module. The RNIS accesses this module via direct method calls. For example, see BaseStationStatsCollector or UeStatsCollector.

Collects the radio network information of a NR UE, which can be accessed by the RniService module of a MecHost. Currently, it exposes the same functionalities as the UeStatsCollector.

Collects the radio network information of a LTE User Equipment (UE), which can be accessed by the RniService module of a MecHost. For example, this module provides information such as packet delay and discard rate.

Maps IP 4-Tuples to Traffic Flow Template (TFT) identifiers, which are used by the GtpUser module contained in the same node. It interacts with the Binder to determine the destination of the packet. Resides in any module that also includes a GtpUser module, such as eNodeB, gNodeB, PgwStandard, Upf, and MecHost modules. For instance, in a Upf module acting as the entry point of the 5G network, it identifies the destination endpoint of the GTP tunnel that the packet should traverse, which is the gNodeB serving the destination User Equipment (UE).

One gNodeB served by a Upf core, a router in front of the Upf, and one NrUe. numExtCells ExtCell cells can be added as interferers. The router has no simulated peer: the host it talks to, and the applications on the NrUe, are configured in the ini file.

ExtClientServerExample with background cells instead of external ones: one gNodeB served by a Upf core, a router in front of the Upf, one NrUe, and numBgCells BackgroundCell cells. The router has no simulated peer: the host it talks to, and the applications on the NrUe, are configured in the ini file.

One gNodeB served by a Upf core, a router in front of the Upf, and two NrUe terminals. numExtCells ExtCell cells can be added as interferers. The router has no simulated peer: the host it talks to, and the applications on the UEs, are configured in the ini file.

One gNodeB and one MecHost hung off the same intermediate Upf, behind an anchor Upf that carries the Ualcmp and, behind it, the MecOrchestrator, plus one NrUe. Nothing here is external: which node talks to a real host, and over which interface, is configured in the ini file.

One gNodeB and one MecHost hung off the same intermediate Upf, behind an anchor Upf that carries the Ualcmp and, behind it, the MecOrchestrator, plus one NrUe. Nothing here is external: which node talks to a real host, and over which interface, is configured in the ini file.

One gNodeB and one MecHost hung off the same intermediate Upf, behind an anchor Upf that carries the Ualcmp and, behind it, the MecOrchestrator, plus one NrUe. Nothing here is external: which node talks to a real host, and over which interface, is configured in the ini file.

Implements the MEC platform manager (MECPM) entity within the MecHost. It serves as an interface between the MEC orchestrator and the MEC host itself. Specifically, it manages interactions with the VirtualisationInfrastructureManager to instantiate and terminate MEC applications upon requests from the MEC orchestrator.

Models the functionalities of the MEC orchestrator within a Multi-access Edge Computing (MEC) system. Specifically, it manages the dynamic instantiation and termination of MEC applications on the MEC hosts belonging to the MEC system. Upon receiving a MEC app instantiation request from the Ualcmp module, this module is responsible for selecting the MEC host on which the MEC application is to be instantiated, according to a configurable policy.

Defines the structure to be implemented by every MEC Application that supports standard lifecycle management via Ualcmp and MecOrchestrator (i.e., MEC applications that can be instantiated dynamically by User Equipment). See, for example, the MecResponseApp module.

Represents the MEC Platform entity within a MecHost, as specified in the ETSI MEC architecture (ETSI GS MEC 003). It encompasses the MEC services made available to MEC applications instantiated within the MEC Host, along with the ServiceRegistry. The type and number of available MEC services can be configured.

Models the functionalities of the Service Registry entity in the MEC architecture (ETSI GS MEC 003). It exposes a REST API compliant with ETSI GS MEC 011, allowing MEC applications to discover MEC services available in the MEC host. In particular, MEC applications can obtain the IP address and port number for each instantiated MEC service, so that they can start sending requests to it

Defines the structure that must be implemented by every MEC Service (see, e.g., LocationService). Common MEC service functionalities are provided by the MecServiceBase class, which includes support for both request-response and subscribe-notification paradigms over the TCP protocol. Furthermore, the MecServiceBase class includes mechanisms to enqueue MEC applications' requests to a MEC service in a FIFO queue, allowing the MEC service to serve them one at a time. This class also calculates the computation time of each request according to an exponential distribution.

This simple module is responsible for managing the state of TCP connections for MEC services. It is instantiated by MecServiceBase to handle each new connection, utilizing the inet::TcpSocket::CallbackInterface. It processes incoming HTTP packets and manages requests and responses within the system.

Implements the Location Service API as defined by the ETSI GS MEC 013 specification. It exposes a REST API that allows MEC applications to retrieve location-related information about User Equipment (UE) or a group of UEs. It supports both request-response and subscribe-notification patterns (in the latter case, the MEC application will be notified when a target UE enters a specific circular area.

Implements a subset of the Radio Network Information Service API defined by the ETSI GS MEC 012 specification. It exposes a REST API that allows MEC applications to retrieve layer-2 measurements related to a User Equipment (UE) or base station.

Represents a host performing the functions of the User Application Lifecycle Management Proxy (UALCMP) defined by the ETSI Multi-access Edge Computing (MEC) specifications. It includes a complete network protocol stack and a UalcmpApp application module that implements the logic of the UALCMP entity. It is typically connected directly to a MEC orchestrator, and forwards to it the creation and deletion requests from the Device App modules of User Equipment. It can be configured to receive packets from a real, external Device App application via the external Ethernet interface submodule.

Implements (part of) the Mx2 reference point defined by the ETSI GS MEC 016 V2.2.1 (2020-04) specification. A DeviceApp application module can use this API to request MEC app lifecycle operations (i.e., instantiation, termination, relocation). In particular, it provides the following methods:

Represents the Virtualisation Infrastructure in a MEC host. It takes care of forwarding packets coming from the 5G core network to the appropriate MEC applications, applying the processing required by all the necessary network protocol layers. Optionally, it can host "independent" MEC applications, i.e., applications that are statically created at initialization, without going through the normal lifecycle (i.e., through the UALCMP and MEC orchestrator). It provides the external interface to communicate with emulated MEC applications, running outside the simulation environment.

Can be used to simulate a background application running on the MEC host without simulating all message exchanges and finite-state machines. It can be useful for simulating background tasks that utilize CPU, RAM, and disk resources.

Manages the computing resources currently allocated to MEC applications hosted by a MEC host. It is also used by MEC applications in case they want to compute a processing delay based on such resource usage.

Simulates a traffic light in an urban environment. It incorporates a stationary mobility submodule to represent the fixed position of the traffic light, and a TrafficLightController submodule to model the traffic light's states (green, yellow, red) and its interactions with vehicles.

Defines the behavior of traffic light controllers in the simulation. It manages the states of the traffic lights (green, yellow, red) and handles the interactions with vehicles, thus influencing the behavior of a node implementing the TrafficLightMobility mobility model when such a node reaches the position of the traffic light. This module allows for the configuration of the duration of green-yellow-red cycles.

Extends INET's Linear Mobility model to simulate the movement of a vehicle navigating roads with intersections regulated by traffic lights. The node implementing this mobility model moves at a constant speed and, if it encounters a TrafficLight module with a "red" color, it stops until the traffic light turns "green". Upon resuming its movement, the node may change its direction if the "enableTurns" parameter is enabled. This module requires the presence of TrafficLight modules in the same network scenario.

Implements a lightweight model for a 4G eNodeB or 5G gNodeB for generating configurable inter-cell interference in the simulated network.

Models an evolved Node B (eNB) of a 4G LTE network. It is a specialized device equipped with a Network Interface Card (NIC) that enables communication with the LteUe devices connected to it. It serves as an access point that routes packets between the UEs and the 4G Core Network. Packets arriving from the UEs are tunneled to the appropriate next hop in the core network (e.g., the PDN Gateway, PGW) using the GPRS Tunneling Protocol (GTP). Conversely, packets received from the core network are detunneled and sent to the appropriate destination UE. In addition to the 4G NIC, this compound module includes a configurable number of wired interfaces to connect with routers of the core network or directly to the PgwStandard module, which serves as the IP module to perform forwarding, and the GtpUser module that handles GTP (de)tunneling. The latter utilizes the TrafficFlowFilter module to classify incoming packets and determine the next hop. Furthermore, it features a configurable number of LteX2App modules to facilitate peer-to-peer communications with other eNodeBs within the same LTE network.

The ExtCell module represents a fictitious cell that is used to model interference from neighboring cells, without actually instantiating them completely (i.e., without having actual UEs producing actual traffic). It can be configured with physical layer parameters (such as transmission power and direction) and the amount of resource occupation. Can be replaced by BackgroundCell modules, which provide more flexibility.

Implements a gNodeB for a 5G network. It extends the eNodeB module by providing 5G connectivity to NrUe modules. It can be used in either StandAlone (SA) or Non-StandAlone (NSA) 5G deployments. In the former case, it is directly connected to a Upf module. In the latter case, this module can be configured as a secondary node of a eNodeB module, thus enabling E-UTRA Dual Connectivity (EN-DC).

Defines a LteCar node as a LTE User Equipment (UE) with vehicular-like mobility. This behavior is modeled by utilizing the Veins-Inet project.

Models a User Equipment (UE) in a 4G LTE network. It is a host equipped with an LTE Network Interface Card (NIC), allowing the UE to connect to an eNodeB module via the Radio Access Network (RAN) of the LTE network and communicate with any other host in the system. In addition to a NIC submodule, this compound module includes all the higher layers of the protocol stack, from IP to application modules. It supports a configurable number of UDP and TCP applications. It also features an Ethernet interface, which is utilized in real-time emulation mode to connect the UE to the real network (outside the simulator) via a virtual Ethernet interface.

Represents a model of a Multi-access Edge Computing (MEC) host belonging to a MEC system, as specified by the ETSI GS MEC 003 specifications. It runs MEC applications within its VirtualisationInfrastructure and can provide a number of MEC services via the MEC platform. MEC applications can be created either dynamically by the MEC orchestrator or statically at the initialization of the simulation. The MEC host possesses a configurable number of computing resources (such as CPU speed, RAM, and storage) and keeps track of the utilization of these resources by the MEC applications via the VirtualisationInfrastructureManager. Moreover, this module includes a User Plane Function (UPF) that allows it to be connected with the 5G core network.

Defines a LteCar node as an NR User Equipment (UE) with vehicular-like mobility. The latter is modeled by utilizing the Veins-Inet project.

Models a User Equipment (UE) for a 5G/LTE network. It extends the LteUe module by implementing a NrNicUe as a Network Interface Card (NIC) module. This module can be used to model a device that can connect to either a 4G eNodeB or a 5G gNodeB, or both.

Implements a simplified EPC PDN Gateway (P-GW) of a 4G LTE network. It serves as the entry point to the core network of an LTE network, thus bridging it to the rest of the Internet. Packets arriving from the Internet are tunneled to the appropriate next hop in the core network (e.g., the eNodeB that will transmit the packet to the destination User Equipment through the radio access network) using the GPRS Tunneling Protocol (GTP). Conversely, packets received from the core network are detunneled and sent to the Internet (e.g., towards a remote server). To accomplish this, it utilizes a GtpUser module that handles GTP (de)tunneling, along with the TrafficFlowFilter module, which classifies incoming packets.

Implements the 5G Core User Plane Function (UPF).

Two eNodeB cells on a shared EPC PgwStandard, joined by an X2 link, with a router and a server behind the core. Four LteUe terminals are placed two per cell, and numExtCells ExtCell cells can be added as interferers.

Five eNodeB cells, each reaching the EPC PgwStandard through a router of its own, with a further router and a server behind the core. There are no X2 links. numUe1 to numUe5 LteUe terminals attach per cell, and an EventGenerator and a MultihopD2DStatistics module sit beside them, wired to nothing.

Three eNodeB cells in a full X2 mesh. Each reaches the EPC PgwStandard through a router of its own, and the server sits directly on the PgwStandard's data-network gate. numUe1, numUe2 and numUe3 LteUe terminals attach per cell, and numExtCells ExtCell cells can be added as interferers.

The minimal LTE topology: one eNodeB connected to an EPC PgwStandard, which faces a router and a server, plus numUe LteUe terminals.

SingleCell with its UEs split into three vectors, so that a configuration can address cellular terminals (ueCell), D2D transmitters (ueD2DTx) and D2D receivers (ueD2DRx) separately. The rest of the topology is the same: one eNodeB on an EPC PgwStandard, with a router and a server behind it.

SingleCell with its UEs split into cellular terminals (ueCell) and members of a D2D multicast group (ueD2D). The rest of the topology is the same: one eNodeB on an EPC PgwStandard, with a router and a server behind it.

Two gNodeB cells, each on an intermediate Upf of its own with a MecHost hung off it, so every cell has its own MEC host. Both intermediate Upf nodes meet at the anchor Upf, which carries the Ualcmp and, behind it, the MecOrchestrator. An X2 link joins the two gNodeBs. numUe NrUe terminals attach, and numBgCells BackgroundCell cells can be added as interferers.

Two operator networks side by side. Each has three gNodeB cells chained by X2, an intermediate Upf that feeds them and carries the operator's MecHost, an anchor Upf, and a Ualcmp with its MecOrchestrator. The two anchor Upf nodes meet at a shared router, the only node the operators have in common. numUe_A and numUe_B NrUe terminals attach to operator A and B respectively, and numBgCells BackgroundCell cells can be added as interferers.

MultiMecHost with the two intermediate Upf nodes linked directly to each other, and with no X2 link between the gNodeBs. The length of that link -- and so its propagation delay -- follows the routersDelay parameter, which makes the distance between the two MEC hosts configurable.

The topology of SingleMecHost -- one gNodeB and one MecHost on a shared intermediate Upf, with a Ualcmp and a MecOrchestrator behind the anchor Upf -- without its playground size parameters. numUes NrUe terminals attach to the gNodeB.

One gNodeB and one MecHost hung off the same intermediate Upf, behind an anchor Upf that carries the Ualcmp and, behind it, the MecOrchestrator. numUes NrUe terminals attach to the gNodeB.

Two gNodeB cells served by a 5G core: the anchor Upf faces the data network (a router and a server), an intermediate Upf feeds both gNodeBs, and an X2 link joins them. numUe NrUe terminals attach, and numBgCells BackgroundCell cells can be added as interferers.

The two-cell version of SingleCell_withSecondaryGnb: two eNodeB masters, each paired over X2 with its own gNodeB secondary, and a further X2 link between the two masters. Both eNodeBs connect to the EPC PgwStandard, which faces a router and a server; neither gNodeB has a core-network link. numUe NrUe terminals attach, and numBgCells BackgroundCell cells can be added as interferers.

One gNodeB served by a 5G core: the anchor Upf faces the data network (a router and a server), and an intermediate Upf sits between it and the gNodeB. numUe NrUe terminals attach to the gNodeB, and numBgCells BackgroundCell cells can be added around it as interferers.

SingleCell_Standalone with its UEs split into three vectors, so that a configuration can address cellular terminals (ueCell), D2D transmitters (ueD2DTx) and D2D receivers (ueD2DRx) separately. The rest of the topology is the same: one gNodeB behind an intermediate and an anchor Upf, with a router and a server on the data network, plus numBgCells BackgroundCell interferers.

The mirror image of SingleCell_withSecondaryGnb: here the gNodeB is the master node and the eNodeB is its secondary, so the UE is anchored on its NR stack and its LTE stack carries the secondary cell group. All data-plane traffic enters at the gNodeB.

An EN-DC topology: an eNodeB master paired over X2 with a gNodeB secondary. The eNodeB is the only node with a core-network link -- an EPC PgwStandard facing a router and a server -- so all data-plane traffic enters there, and the gNodeB contributes its radio leg alone. numUe NrUe terminals attach to both, and numBgCells BackgroundCell cells can be added as interferers.

Interface for the 3GPP Stack.

The LteNicBase module serves as the foundational building block for LTE networking in Simu5G. It integrates protocols for LTE communication, including PDCP, RLC, MAC, and PHY layers. This base module allows higher-level modules, such as User Equipment (UE) and eNodeB (evolved Node B), to configure and utilize these layers according to their specific requirements.

The LteNicEnb module is a network interface that provides LTE connectivity within an eNodeB. It implements the data and signaling planes of the LTE stack, which includes the PDCP, RLC, MAC, and PHY layers. The parameters and submodules allow customization of the eNodeB's behavior, including whether it supports D2D communication, CoMP (Coordinated MultiPoint), or dual connectivity.

The LteNicUe module is a network interface that provides LTE connectivity within a UE (User Equipment). It implements the data and signaling planes of the LTE stack, which includes PDCP, RLC, MAC, and PHY layers. The parameters and submodules allow customization of the UE's behavior.

The NrNicEnb module serves as a network interface that provides 5G connectivity within a gNodeB. It implements the data and signaling plane of the NR (New Radio) stack, which encompasses the PDCP, RLC, MAC, and PHY layers. The parameters and submodules facilitate the customization of the gNodeB's behavior, including its support for CoMP (Coordinated MultiPoint) or dual connectivity. D2D support is added by the NrNicEnbD2D subtype.

Defines a User Equipment (UE) network interface card that supports both LTE and NR (New Radio) technologies. It extends the LteNicUe module by adding additional submodules and parameters to support NR-specific functionalities. D2D support is added by the NrNicUeD2D subtype.

The LteCompManager interface defines the structure for the CoMP Manager. It extends the X2User interface and provides the necessary parameters and configurations for managing Coordinated Multi-Point (CoMP) communications in LTE networks.

Serves as the base class for Coordinated Multi-Point (CoMP) manager modules in LTE networks. It provides essential functionalities and parameters needed to manage CoMP operations. To implement a specific CoMP algorithm, extend this class and override its pure virtual methods.

Implements a CoMP (Coordinated Multi-Point) Proportional Scheduling algorithm. It allows for coordinated scheduling among multiple eNodeBs by calculating the required Resource Block (RB) allocation proportionally based on user load. In this structure, the module can function as either a master or a slave node. Slave nodes send their RB requests to the master node, which then processes these requests by partitioning the available bandwidth and subsequently informs each slave node about the available RBs for transmission.

The LteNicEnbD2D module represents an LTE eNodeB network interface with support for D2D (Device-to-Device) communications. It extends the basic LteNicEnb module to manage D2D-capable UEs (User Equipments). A D2D mode selection algorithm can be specified via the rrc.d2dModeSelection submodule's typename.

Represents a Device-to-Device (D2D) capable User Equipment (UE) network interface. It extends the basic LTE UE functionality by adding D2D communication capabilities, allowing direct communication between UEs without the need to route traffic through the base station.

Device-to-Device (D2D) capable NR gNodeB network interface. It extends NrNicEnb by swapping in the D2D-capable NR MAC leaf and the D2D-capable eNB PHY, and by enabling the D2D mode controller and mode selection. It is the NR counterpart of LteNicEnbD2D.

Device-to-Device (D2D) capable NR User Equipment network interface. It extends NrNicUe by swapping in the D2D-capable NR MAC/PHY leaves and enabling the D2D mode controller, allowing direct UE-to-UE communication without routing traffic through the gNodeB. It is the NR counterpart of LteNicUeD2D.

Global holder of the D2D-specific network state, split out of the core Binder.

Device-to-Device (D2D) aware version of Ip2Nic. It overrides the packet analysis and next-hop resolution with the D2D-capable behavior: IP-multicast becomes a D2D_MULTI flow with a group-id assignment, unicast destinations get a D2D peer lookup, and the next hop is routed directly to the peer when the peering is in Direct Mode (DM). Selected by the D2D-capable NICs.

Extends LTE MAC functionalities at the eNodeB side to support device-to-device (D2D) communications. Specifically, it enhances resource allocation procedures to enable direct communication between User Equipments (UEs), i.e., it allocates resources for D2D transmissions. Network-assisted D2D is only implemented (out-of-coverage D2D is not supported).

Extends LTE MAC functionalities at the User Equipment side to support device-to-device (D2D) communications. Specifically, it customizes LteMacUe functionalities to support the transmission and reception of MAC Protocol Data Units (PDUs), Channel Status Information (CSI), and Buffer Status Reports (BSRs) over a D2D link. It supports D2D multicast transmission to nearby UEs belonging to a given multicast group.

NR-gNB MAC with D2D support. Extends NrMacGnb with the device-to-device (D2D) deltas: it enhances resource allocation procedures to enable direct communication between UEs (network-assisted D2D). It is the NR counterpart of LteMacEnbD2D.

NR-UE MAC with D2D support. Extends NrMacUe with the device-to-device (D2D) deltas: it customizes the numerology-aware MAC to support the transmission and reception of MAC PDUs, CSI, and BSRs over a D2D link, including one-to-many D2D multicast transmission. It is the NR counterpart of LteMacUeD2D.

LTE Adaptive Modulation and Coding (AMC) module with D2D support. It is the D2D-capable variant of LteAmc, wired in by the D2D LTE NICs via the MAC's amcType parameter.

NR Adaptive Modulation and Coding (AMC) module with D2D support. It is the D2D-capable variant of NrAmc, wired in by the D2D NR NICs via the MAC's amcType parameter.

LTE eNB uplink scheduler with device-to-device (D2D) support. It is the D2D-capable variant of LteSchedulerEnbUl, wired in by the D2D LTE MAC via the ulSchedulerType parameter.

NR gNB uplink scheduler with device-to-device (D2D) support. It is the D2D-capable variant of NrSchedulerGnbUl, wired in by the D2D NR MAC via the ulSchedulerType parameter.

Extends the PHY functionalities on the eNodeB side to support device-to-device (D2D) communications. Specifically, it enables the computation of Channel Status Information (CSI) related to the D2D link between two UEs, which still needs to be stored at the eNodeB for scheduling purposes.

Extends the PHY functionalities at the User Equipment side to support device-to-device (D2D) communications. Specifically, it customizes the PhyUe functionalities to support the transmission and reception of frames to another UE directly, without going through the serving eNodeB. It also supports one-to-many D2D transmission to UEs belonging to a multicast group. It is assumed that one-to-one D2D communication is only possible when both endpoints are served by the same eNodeB. When a handover is triggered, this module is responsible for initiating a mode switch from direct (D2D) mode to infrastructure mode.

D2D-capable channel model: StochasticChannelModel plus the device-to-device channel math (RSRP/SINR, D2D interference, D2D reception decision). It is the channel model of the D2D NICs on all propagation studies; the pathLossType parameter (inherited from StochasticChannelModel) selects TR 36.814, 36.873 or 38.901.

RLC UM entity of a D2D-capable LTE data radio bearer: LteRlcUmEntity with both sides bound to the D2D entity profiles. Selected by BearerManagement on the D2D-capable NICs via its lteRlcUmEntityModuleType parameter.

D2D-capable LTE (TS 36.322) RLC UM receiving entity: LteRlcUmRxEntity plus the D2D_MULTI single-PDU reordering window, the post-mode-switch reassembly resynchronisation, and the D2D branch of the throughput/delay statistics.

D2D-capable LTE (TS 36.322) RLC UM transmitting entity: LteRlcUmTxEntity plus the D2D mode-switch machinery (SDU holding buffer, drain notification to the D2DModeController, sequence-number reset on the newly selected mode).

RLC UM entity of a D2D-capable NR data radio bearer: NrRlcUmEntity with both sides bound to the D2D entity profiles. Selected by BearerManagement on the D2D-capable NICs via its nrRlcUmEntityModuleType parameter.

D2D-capable NR (TS 38.322) RLC UM receiving entity: NrRlcUmRxEntity plus the mode-switch buffer discard/renumbering and the D2D branch of the throughput/delay statistics.

D2D-capable NR (TS 38.322) RLC UM transmitting entity: NrRlcUmTxEntity plus the same D2D mode-switch machinery as LteRlcUmTxEntityD2D, over the SO segmentation buffer.

Device-to-Device (D2D) aware version of RlcMux. It additionally handles D2D mode switch notifications arriving from the MAC layer, dispatching them to the TX or RX UM entity of the affected bearer, and declares the D2D statistics (emitted by the D2D UM entities). Selected by the D2D-capable NICs.

Controls D2D mode switching flow control.

Base module for D2D Mode Selection modules.

Implements the mode selection algorithm for D2D communications that selects the mode based on the best Channel Quality Indicator (CQI). It evaluates the CQI for each D2D-capable flow and selects the communication mode that provides the best performance in terms of achievable data rate. The primary goal is to optimize data transmission quality and efficiency by dynamically switching between modes based on CQI measurements.

D2D-capable variant of the HandoverController. It fills in the handover lifecycle hooks with D2D behavior: switching active D2D flows back to infrastructure mode before a handover, detaching/attaching the D2D AMC direction while executing it, and re-selecting the D2D mode once the handover has completed. Selected via 'handoverController.typename' / 'nrHandoverController.typename' by the D2D-capable UE NICs.

Interface for the D2D mode controller of the IRrc layer: performs the D2D mode switch of a peering, draining and re-routing the affected RLC transmission buffers.

Interface for the D2D Mode Selection module

D2D-capable variant of the Rrc layer. It adds the D2D mode controller (which coordinates RLC TX-queue draining across a mode switch) and, on the eNB/gNB side (hasD2DModeSelection==true), the periodic D2D mode selection module. Selected via 'rrc.typename' by the D2D-capable NICs.

Performs bridging of data-plane packets between PDCP entities of two eNodeBs or gNodeBs when Dual Connectivity is employed. The module directly interfaces with the LteX2Manager to transfer such packets over the X2 interface.

Interface for the DC X2 Forwarder. This module extends the IX2User module interface to define the basic contract that any DC X2 Forwarder must adhere to.

Manages the exchange of messages during the handover process. It handles the signaling and coordination required to transfer both control and data-plane information from the source eNodeB to the target eNodeB. The module directly interfaces with the LteX2Manager to facilitate this inter-eNodeB communication.

Interface for the Handover X2 Forwarder. This module extends the IX2User module interface to define the basic contract that any Handover X2 Forwarder must adhere to.

Manages packet buffering and forwarding during handover procedures at the base station. When a user equipment begins handover, tunnels downlink packets to the target base station via the backhaul interface. At the target base station, buffers incoming packets from both the backhaul tunnel and the network layer. Upon handover completion, releases buffered packets to the protocol stack in the correct order.

Manages uplink packet buffering during handover at the user equipment. Temporarily holds packets from the network layer when handover is in progress. Whether the UE is attached at all is read from a mirror of RRC's stack attachment ledger, which RRC pushes on every handover event (see BearerManagement). Releases buffered packets to the protocol stack once handover completes successfully.

Manages packet buffering/tunnelling during handover

The INetworkLayer2CellularNic module interface serves as an intermediary between the network layer and the cellular (LTE/NR) protocol stack. It facilitates interactions between the cellular stack and the network layer, enabling the transmission of IP packets through the protocol layers of LTE and NR technologies.

Bridges the IP network layer and the cellular protocol stack, handling bidirectional packet flow. Extracts flow information from IP headers and attaches it as control tags for the stack. In base stations, determines the destination user equipment from IP addresses.

Interface for the Medium Access Control (MAC) layer of the LTE Stack.

Base module for the Medium Access Control (MAC) layer of the LTE protocol stack.

Extends the LteMacBase module by providing specific MAC functions on the eNodeB side. Specifically, it initializes and manages the scheduling classes responsible for resource allocation operations in both uplink and downlink directions, while also supporting Carrier Aggregation (CA). It manages the Random Access procedure (RAC) and the reception of Buffer Status Reports (BSRs) from UEs, as well as the transmission of scheduling grants to UEs allocated within the uplink bandwidth. For downlink connections, it notifies the Radio Link Control (RLC) layer when it is ready to receive MAC Service Data Units (SDUs) to build MAC Protocol Data Units (PDUs) and transmit them to the physical layer.

Extends the LteMacBase module by providing specific MAC functions at the User Equipment (UE) side. For uplink connections, this module manages the initiation of the Random Access procedure (RAC) and the sending of Buffer Status Reports (BSRs) to the eNodeBs. Once it receives an uplink scheduling grant from the eNodeB, it is responsible for managing the local connections' scheduler and constructing MAC Protocol Data Units (PDUs) to be transmitted to the physical layer.

Provides functionalities for the Medium Access Control (MAC) of the New Radio (NR) protocol stack at the gNodeB (gNB) side. In particular, it extends the LteMacEnb module by initializing the NR version of the uplink scheduler and using, by default, the NR version of the Adaptive Modulation and Coding (AMC) module.

Provides functionalities for the Medium Access Control (MAC) of the New Radio (NR) protocol stack at the User Equipment (UE) side. In particular, it extends the LteMacUe module by redefining functions to support different numerology parameterizations.

Module interface for the Adaptive Modulation and Coding (AMC) module.

LTE Adaptive Modulation and Coding (AMC) module.

NR Adaptive Modulation and Coding (AMC) module.

Module interface for the eNB/gNB downlink scheduler.

Module interface for the eNB/gNB uplink scheduler.

LTE eNB downlink scheduler module.

LTE eNB uplink scheduler module.

NR gNB uplink scheduler module.

This module is responsible for keeping tracking the flow of SDUs in the stack, and compute statistics from them. It is passive observer of the packet flow. Its main user is MEC services.

This module is responsible for keeping tracking the flow of SDUs in the stack, and compute statistics from them. It is passive observer of the packet flow. Its main user is MEC services.

This module is responsible for keeping tracking the flow of SDUs in the stack, and compute statistics from them. It is passive observer of the packet flow. Its main user is MEC services.

This module is responsible for keeping tracking the flow of SDUs in the stack, and compute statistics from them. It is passive observer of the packet flow. Its main user is MEC services.

Dual Connectivity mux: routes split-bearer PDCP PDUs between the local PDCP entities and the DcX2Forwarder, which tunnels them to the peer eNB/gNB over X2.

TX-side leg dispatcher of a dual-connectivity split bearer (two legs), steering each PDCP PDU to a leg from the split policy RRC pushes off the bearer's definition (TS 38.331 PDCP-Config, TS 38.323 5.2.1). A splitter serves exactly one direction: a UE's TX side is uplink, a base station's is downlink.

Module interface for the RX-side leg merger of a multi-leg PDCP entity (see PdcpEntityBase): implementations merge the PDU streams of all legs into the single RX entity, whose reorder window restores SN order across legs. Instantiated by the PdcpEntityBase compound via a typename parameter when the bearer has more than one leg.

Module interface for the TX-side leg dispatcher of a PDCP entity (see PdcpEntityBase): implementations pick the RLC leg for each PDCP PDU and apply that leg's id mapping. Instantiated by the PdcpEntityBase compound via a typename parameter when a leg needs it: on a multi-leg bearer, and on a single-leg bearer whose leg is not the anchor's (an SCG bearer).

Module interface for the upper-layer PDCP packet dispatcher of a cellular NIC (see PdcpMux for the default implementation). Implementations dispatch SDUs coming from Ip2Nic/SDAP to the PDCP TX entity serving their DRB, and pass the output of the RX entities back up. The per-bearer gates are created and wired at runtime by BearerManagement, which also registers the TX routing table; implementations must therefore subclass the PdcpMux C++ class.

Module interface for the receiving side of a PDCP entity. Concrete types (LtePdcpRxEntity, NrPdcpRxEntity) implement it so the PdcpEntityBase compound can instantiate them via a typename parameter. The RX entity is leg-agnostic; on a multi-leg bearer the compound's joiner merges all legs into its single input, and its reorder window restores SN order (see PdcpEntityBase).

Module interface for the transmitting side of a PDCP entity. Concrete types (LtePdcpTxEntity, NrPdcpTxEntity) implement it so the PdcpEntityBase compound can instantiate them via a typename parameter. The TX entity is leg-agnostic (SN assignment, header compression); leg dispatch is the enclosing compound's concern (see PdcpEntityBase).

PDCP entity of an LTE data radio bearer: the PdcpEntityBase compound with its TX/RX sides bound to the LTE entity profiles (TS 36.323). Selected by BearerManagement via its pdcpEntityModuleType parameter, which defaults to this type.

Handles the operations related to the LTE PDCP (Packet Data Convergence Protocol) layer at the receiving side of a specific connection. It processes incoming PDCP PDUs from the RLC layer, performing header decompression before forwarding them to the upper layer protocols.

Handles operations related to the LTE PDCP (Packet Data Convergence Protocol) layer on the transmitting side of a specific connection. This module manages the creation, sequencing, header compression, and metadata association for PDCP PDUs before they are passed down to the RLC layer.

PDCP entity of an NR data radio bearer: the PdcpEntityBase compound with its TX/RX sides bound to the NR entity profiles (TS 38.323), i.e. NR-flavored statistics on the TX side and the multi-leg reorder window on the RX side. Selected by BearerManagement via its pdcpEntityModuleType parameter (set by NrNicUe/NrNicEnb, and on EN-DC master eNBs from the configuration).

Handles the operations related to the NR PDCP (Packet Data Convergence Protocol) layer on the receiving side of a specific connection. It extends the LtePdcpRxEntity module. Facilitates the creation of support for Dual Connectivity functionality. In particular, it manages the reordering of out-of-sequence PDCP PDUs in Dual Connectivity deployments.

Handles the operations related to the NR PDCP (Packet Data Convergence Protocol) layer at the transmitting side of a specific connection. It extends the LtePdcpTxEntity module with the NR flavor of the per-SDU statistics (pdcpSduSentNr) and the NR-leg id mapping of a single-leg NR bearer. On a multi-leg bearer, leg dispatch, id mapping and per-leg statistics are handled by the enclosing compound's splitter instead (see PdcpEntityBase).

Downlink half of a DC-secondary PDCP relay (see PdcpRelayEntity): receives an already-processed PDCP PDU that the master forwarded over X2 and passes it straight to the local RLC, doing no PDCP processing of its own.

Base type of the PDCP entity of one data radio bearer: packages the transmitting and the receiving side of TS 36.323 / 38.323, plus the leg split/join stage of a multi-leg bearer (e.g. an NR dual connectivity split bearer). Created dynamically by BearerManagement, one per (peer, DRB) pair.

RX-side leg merger of a multi-leg PDCP entity (see PdcpEntityBase): relays the PDU streams of all legs into the single RX entity, whose one reorder window restores SN order across legs (the join needs no logic of its own -- the SN space is common to all legs by construction).

Upper-layer PDCP packet dispatcher.

Stands in place of the PDCP entity of a data radio bearer at a dual-connectivity SECONDARY node. The bearer's real PDCP entity lives at the master; the secondary only tunnels the already-processed PDUs between the master (over X2, via the DcMux) and its own RLC, doing no PDCP processing of its own. Created dynamically by BearerManagement, one per (UE, DRB) pair, in place of a PdcpEntityBase.

Uplink half of a DC-secondary PDCP relay (see PdcpRelayEntity): receives a PDCP PDU from the local RLC (UL from the UE) and forwards it to the master node over X2, doing no PDCP processing of its own.

Interface for the Physical (PHY) layer of the LTE/NR protocol stack.

Base module for the Physical (PHY) layer of the LTE/NR protocol stack.

Extends the PhyBase module by providing the specific PHY functions on the eNodeB side. It is responsible for checking if a frame received on the air interface originates from a User Equipment (UE) connected to the eNB itself, and it provides the functions necessary to compute the Channel Status Information (CSI) for the UEs connected to it.

Extends the PhyBase module by providing specific PHY functions on the User Equipment (UE) side. It ensures that frames received on the air interface are sourced from the serving eNodeB (eNB) and provides functions to manage the handover procedure, including periodic measurement of channel conditions to determine when a handover should occur. If enabled, the selection of the serving eNB at initialization is done dynamically based on radio conditions.

This is the base module for developing more realistic models of the radio channel. It primarily provides the initialization of parameters such as the reference to the Component Carrier (CC) and its associated parameters related to the channel model itself.

Provides the interface for modules implementing the model of the radio channel. Such modules are responsible for providing functions to compute the Signal to Interference-plus-Noise Ratio (SINR) of received frames, taking into account channel effects such as propagation loss, fading/shadowing, and inter-cell interference.

A channel model that replaces propagation modelling with a configurable packet error rate. Path loss, shadowing and fading are not modelled at all: the attenuation is zero and the reported SINR/RSRP are a fixed large value, so the CQI reported to the scheduler is pinned at its maximum and the transport block size never varies with the channel.

The full PHY link model: everything between a transmitted air frame and the decision on whether it was received. The channel impairments are modeled statistically -- drawn from the distributions of a 3GPP propagation study, rather than computed from the geometry of an actual environment -- which is what sets this model apart from IdealChannelModel, where there are no impairments at all, only a configured packet error rate.

StochasticChannelModel preset with the propagation formulas of 3GPP TR 36.873, "Study on 3D channel model for LTE", v12.7.0, December 2017. It differs from its base type only in the pathLossType default; there is no C++ class of its own behind the name. Note that the study supplies the path loss, LOS probability, shadowing and angular attenuation only; the rest of the link model is the same for every propagation study.

StochasticChannelModel preset with the propagation formulas of 3GPP TR 38.901, "Study on channel model for frequencies from 0.5 to 100 GHz", v16.1.0, December 2019. It differs from its base type only in the pathLossType default; there is no C++ class of its own behind the name. Note that the study supplies the path loss, LOS probability, shadowing and angular attenuation only; the rest of the link model is the same for every propagation study.

This is the Lte Downlink Feedback Generator. It manages periodic and aperiodic channel sensing and feedback transmission.

This is the LTE Uplink Feedback Generator.

A test harness for the downlink feedback generator: one LteDlFeedbackGenerator and one FeedbackTester that drives it. The two are not connected; the tester reaches the generator by module reference.

Receiving side of an RLC AM entity: extends the generic RX interface with the gates over which it hands control PDUs to the co-located transmitting side (see RlcAmEntityBase).

Transmitting side of an RLC AM entity: extends the generic TX interface with the gates over which the co-located receiving side hands it control PDUs (see RlcAmEntityBase).

Module interface for the lower-layer RLC packet dispatcher of a cellular NIC (see RlcMux for the default implementation). Implementations dispatch packets coming from the MAC layer to the RLC RX entity serving their DRB (or, for MAC SDU requests, to its TX entity), and pass the output of the TX entities down to MAC. The per-bearer gates are created and wired at runtime by BearerManagement, which also registers the RX routing table; implementations must therefore subclass the RlcMux C++ class.

Module interface for the receiving side of an RLC entity (TM/UM/AM). Concrete entity types (e.g. RlcTmRxEntity, RlcUmRxEntity, RlcAmRxEntity) implement this interface so that RlcTmEntity/RlcUmEntityBase/RlcAmEntityBase compound modules can instantiate them via a typename parameter. Implementations may declare additional gates (e.g. the AM control gates).

Module interface for the transmitting side of an RLC entity (TM/UM/AM). Concrete entity types (e.g. RlcTmTxEntity, RlcUmTxEntity, RlcAmTxEntity) implement this interface so that RlcTmEntity/RlcUmEntityBase/RlcAmEntityBase compound modules can instantiate them via a typename parameter. Implementations may declare additional gates (e.g. the AM control gates).

RLC AM entity of an LTE data radio bearer: the RlcAmEntityBase compound with its TX/RX sides bound to the LTE (FI wire format, TS 36.322) entity profiles. Selected by BearerManagement for LTE bearers via its lteRlcAmEntityModuleType parameter, which defaults to this type.

RLC UM entity of an LTE data radio bearer: the RlcUmEntityBase compound with its TX/RX sides bound to the LTE (FI wire format, TS 36.322) entity profiles. Selected by BearerManagement for LTE bearers via its lteRlcUmEntityModuleType parameter, which defaults to this type.

RLC AM entity of an NR data radio bearer: the RlcAmEntityBase compound with its TX/RX sides bound to the NR (SI/SO wire format, TS 38.322) entity profiles. Selected by BearerManagement for NR bearers via its nrRlcAmEntityModuleType parameter.

RLC UM entity of an NR data radio bearer: the RlcUmEntityBase compound with its TX/RX sides bound to the NR (SI/SO wire format, TS 38.322) entity profiles. Selected by BearerManagement for NR bearers via its nrRlcUmEntityModuleType parameter.

Base type of the RLC AM entity of one data radio bearer: packages the transmitting and the receiving side into the single bidirectional entity of TS 36.322 / 38.322 section 4.2.1. Created dynamically by BearerManagement, one per (peer, DRB) pair.

Lower-layer RLC packet dispatcher.

RLC TM entity of one data radio bearer: packages the transmitting and the receiving side (TS 36.322 / 38.322 model an entity per bearer). Created dynamically by BearerManagement, one per (peer, DRB) pair; a bearer with traffic in one direction only simply leaves the other side idle.

Base type of the RLC UM entity of one data radio bearer: packages the transmitting and the receiving side (TS 36.322 / 38.322 model an entity per bearer). Created dynamically by BearerManagement, one per (peer, DRB) pair; a bearer with traffic in one direction only simply leaves the other side idle.

LTE (TS 36.322) receiving side of the Acknowledged Mode (AM) of the RLC layer: PDU-SN receiving window with byte-interval coverage for AMD PDU segments, t-Reordering + t-StatusProhibit, ACK_SN + NACK-list STATUS reports, in-order FI-walk reassembly of the concatenated SDU stream. Shares the common RlcAmRxEntityBase shell with the NR profile NrRlcAmRxEntity, whose window/status machinery it deliberately mirrors. Bound by default inside the LteRlcAmEntity compound.

LTE (TS 36.322) transmission side of the Acknowledged Mode (AM) of the RLC layer: one AMD PDU per MAC grant built by concatenation (FI framing), the built PDU as the ARQ unit, NACK-driven retransmission with re-segmentation into AMD PDU segments, pollPDU/pollByte-driven status polling with t-PollRetransmit, and radio link failure at maxRtxThreshold retransmissions. Shares the common RlcAmTxEntityBase shell with the NR profile NrRlcAmTxEntity, whose ARQ skeleton it deliberately mirrors. Bound by default inside the LteRlcAmEntity compound.

NR (TS 38.322) receiving side of the Acknowledged Mode (AM) of the RLC layer: SO byte-coverage reassembly with a per-SDU SN window, t-Reassembly + t-StatusProhibit timers. Shares the common RlcAmRxEntityBase shell with the LTE profile LteRlcAmRxEntity. Bound by default inside the NrRlcAmEntity compound. The NR SO-reassembly statistics are declared here so they are recorded only for NR-selected entities.

NR (TS 38.322) transmission side of the Acknowledged Mode (AM) of the RLC layer: byte-offset (SO) segmentation with re-segmentation on retransmission, pollByte/pollPDU-driven status polling. Shares the common RlcAmTxEntityBase shell with the LTE profile LteRlcAmTxEntity. Bound by default inside the NrRlcAmEntity compound. The NR SO-segmentation statistics are declared here so they are recorded only for NR entities.

Implements the receiving side of the Transparent Mode (TM) of the Radio Link Control (RLC) layer for a specific connection. Simply forwards received PDUs to the upper layer without reassembly or reordering.

Implements the transmission side of the Transparent Mode (TM) of the Radio Link Control (RLC) layer for a specific connection. Buffers SDUs from the upper layer and, upon receiving a MAC SDU request, sends the next queued PDU without segmentation or concatenation.

LTE (TS 36.322) receiving side of the Unacknowledged Mode (UM) of the RLC layer: FI-walk reassembly across concatenated PDUs with a PDU-SN reordering window and a t-Reordering timer. Shares the common RlcUmRxEntityBase shell (MAC-mux plumbing, D2D hooks, UL burst-throughput accounting) with the NR profile NrRlcUmRxEntity. Bound by default inside the LteRlcUmEntity compound. Its throughput/delay statistics are emitted on the sibling rlcMux module (see RlcMux).

LTE (TS 36.322) transmission side of the Unacknowledged Mode (UM) of the RLC layer: FI framing + concatenation of multiple SDUs per PDU, one sequence number per PDU. Shares the common RlcUmTxEntityBase shell (MAC plumbing, D2D mode-switch machinery) with the NR profile NrRlcUmTxEntity. Bound by default inside the LteRlcUmEntity compound.

NR (TS 38.322) receiving side of the Unacknowledged Mode (UM) of the RLC layer: SI + byte-offset (SO) reassembly with a per-SDU SN window and a t-Reassembly timer. Shares the common RlcUmRxEntityBase shell with the LTE profile LteRlcUmRxEntity. Bound by default inside the NrRlcUmEntity compound. The NR SO-reassembly statistics are declared here so they are recorded only for NR entities.

NR (TS 38.322) transmission side of the Unacknowledged Mode (UM) of the RLC layer: SI + byte-offset (SO) segmentation, one SDU segment per PDU, one sequence number per SDU. Shares the common RlcUmTxEntityBase shell (MAC plumbing, D2D mode-switch machinery) with the LTE profile LteRlcUmTxEntity. Bound by default inside the NrRlcUmEntity compound. The NR SO-segmentation statistics are declared here so they are recorded only for NR entities.

RRC Bearer Management — creates and tears down PDCP, RLC and MAC entities for data radio bearers.

The node's data radio bearer configuration: one descriptor per bearer, holding the bearer's SDAP configuration and the RLC/logical-channel configuration of its radio bearer (modeled on the DRB-ToAddMod and RLC-BearerConfig records of TS 38.331).

UE-side component that manages handover decisions and procedures. Receives RSSI measurements from the PHY layer based on broadcast frames, and triggers handover when a better serving cell is detected.

Interface for the bearer management component of the IRrc layer: creates and tears down the PDCP, RLC and MAC entities of data radio bearers.

Interface for the data radio bearer configuration table of the RRC layer.

Interface for the handover controller of the IRrc layer: the UE-side component that tracks the serving cell of one stack leg and runs its handovers. One instance per leg; the Rrc compound instantiates the LTE and the NR one.

Interface for the registration component of the IRrc layer: registers the node (and its stack legs) with the Binder, sets up the network interface, and joins multicast groups.

Interface for the RRC (Radio Resource Control) layer of the LTE/NR Stack.

RRC Registration — registers the node with the Binder, sets up the network interface, and joins multicast groups.

RRC (Radio Resource Control) layer for LTE/NR networks.

Interface for SDAP protocol implementations.

Interface for the UE's uplink QoS-flow classifier (see QosFlowClassifier).

Implements the SDAP Protocol.

Classifies a UE's uplink packets to QoS flows: the uplink counterpart of TrafficFlowFilter's QFI assignment, sitting where uplink traffic enters the UE's stack just as the TFF sits where downlink traffic enters the tunnel at the core network. Each direction is classified once, at its ingress.

Interface for Reflective QoS Table modules.

ReflectiveQosTable maintains a table of QoS flow mappings for reflective QoS.

Utility module that records the position of each radio module in the network. Exactly one instance of this module (or its derived extensions) must be present in the network. Note that channel parameters in this module are obsolete and are not utilized.

Utility module that records the position of each LTE radio module in the network. Exactly one instance of this module must be present in the network. Note that channel parameters in this module are obsolete and not utilized.

Interface for modules that need to interact with the LteX2Manager to utilize X2 communication to perform tasks such as handover, dual connectivity, and Coordinated Multi-Point.

Represents the container for all X2 applications that an e/gNodeB instantiates to enable X2 communications with its peer e/gNodeBs. Specifically, for each peer, this module contains two submodules:

Serves as a pluggable interface for submodules of the e/gNodeB's LTE/NR protocol stack that implement functionalities requiring the use of the X2 interface for communication with peer e/gNodeBs, such as handover, dual connectivity, and Coordinated MultiPoint (CoMP). Simplifies the interaction for such submodules by abstracting the details of X2Apps, which are the modules responsible for the actual communication through the X2 interface.

Extends INET's SctpClient application by adding an output gate to send messages to the LteX2Manager and manages the connection initiation towards the peer's server module based on the configuration specified in the .ini file. Once the connection has been established, it receives messages from the peer's server module and forwards them to the LteX2Manager module for further processing and redirection to the intended submodule of the LTE/NR protocol stack.

Extends the INET's SctpServer application by adding an input gate to receive messages from the X2 Manager module. The X2AppServer module is responsible for handling messages from the X2 Manager and forwarding them to the peer's client X2App via the SCTP layer. It ensures that the messages are properly encapsulated in SCTP packets before being sent.