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

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

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

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

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

This module implements an application for disseminating 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:

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

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

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

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

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

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

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

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

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

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

This module provides an application model to be run at a User Equipment (UE), which generates periodic requests to be sent to a MecResponseApp module hosted on an (edge) host, located next to a base station. For each request, it expects to receive a response from the MecResponseApp. This module records statistics about the Round-trip Time (RTT). Optionally, the effect of migration can be simulated when the User Equipment (UE) performs a handover to a different base station. In this case, the application can be configured to forward new requests to a different (edge) host, namely, the one located next to the new base station.

This module provides a simplified model of an edge application, intended to run on an edge host associated with a base station. It receives requests from a User Equipment (UE) application, such as a MecRequestApp, and sends a response after a processing time. The processing time is calculated based on the size of the request packet and a value representing the computational capabilities of the node hosting this application module. If the UE that sends the request is not served by the base station associated with this application, then an additional delay is applied to the response, which represents the time required to traverse the cellular core network.

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

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

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

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

Binder module

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

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

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

This module 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. This module is used by all entities that need to communicate within the cellular core network, such as eNodeB, gNodeB, PgwStandard, Upf, and MECHost modules.

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

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

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

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

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

This module 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(1,2) to determine the destination of the packet. This module 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).

ExtClientServerExample

ExtClientServer_bgCells

ExtServerExample

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

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

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

This module 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 Ue 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. This module can be replaced by BackgroundCell modules, which provide more flexibility.

This module implements a simplified model of the 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.

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

Implements a 5G Core User Plane Function (UPF) module.

This module implements a lightweight model for a 4G eNodeB or 5G gNodeB. It is used to generate configurable inter-cell interference in the simulated network. Compared to the eNodeB and gNodeB modules, this module occupies time-frequency resources in both the uplink and downlink bandwidth without simulating the actual transmission or reception of data packets to or from User Equipments (UEs). Therefore, it is significantly more efficient from a simulation speed perspective. To achieve this, it includes a BackgroundTrafficGenerator to customize the level of background traffic to be simulated, a BackgroundChannelModel to configure channel parameters, and a BackgroundScheduler that manages the allocation of time-frequency resources based on the traffic generator. Note that this module can generate interference on only one Component Carrier, as configured in the BackgroundScheduler module. To produce interference across multiple carriers, it is possible to use multiple instances of this module, each configured with the desired carrier frequency.

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

This module manages the background traffic generated by BackgroundUe in a BackgroundCell.

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

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

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

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

This module interface defines the structure that every MEC Service must implement (see, e.g., LocationService)

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

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

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

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

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

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

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

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

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

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

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

This module implements a gNodeB for a 5G LTE 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).

This module implements a User Equipment (UE) for a 5G LTE network. It extends the Ue 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.

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 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 using the 'd2dModeSelectionType' parameter.

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.

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

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 D2D communication, CoMP (Coordinated MultiPoint), or dual connectivity.

This module defines a User Equipment (UE) network interface card that supports both LTE and NR (New Radio) technologies. It extends the LteNicUeD2D module by adding additional submodules and parameters to support NR-specific functionalities.

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

This module manages the background traffic generated by BackgroundUe in a eNodeB or gNodeB.

BackgroundTrafficManagerBase

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

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

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

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

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

ALTERNATIVE:

This module implements a simple CoMP (Coordinated Multi-Point) coordinated scheduling algorithm. A CompManager module within an eNodeB can be either a master or a slave. Slave nodes send the master node the number of RBs required to satisfy their users' load. The master node partitions the bandwidth based on these requests and sends back an indication of which RBs are available for transmission and which are not.

Base module for D2D Mode Selection modules.

D2DModeSelectionBestCqi module

Interface for the D2D Mode Selection module

This module is responsible for bridging 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 Dual Connectivity Manager. This module extends the X2User module interface to define the basic contract that any Dual Connectivity Manager must adhere to.

Interface for the Handover Manager. This module extends the X2User module interface to define the basic contract that any handover manager must adhere to.

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

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.

The IP2Nic module acts as a bridge between the IP network layer and the cellular (LTE/NR) protocol stack. It exhibits slightly different behavior when operating in the UE compared to the BS. Its main functionalities include:

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.

This module extends the LteMacBase(1,2) 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.

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

This module extends the LteMacBase(1,2) 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.

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

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

This 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 LteMacUeD2D module by redefining functions to support different numerology parameterizations.

NRPacketFlowManagerGnb is designed to handle packet flow management operations specifically for NR (New Radio) e/gNodeB in 5G simulations. It ensures that data packets are managed efficiently in a 5G network scenario, providing an accurate model of packet handling mechanisms.

This simple module represents the Packet Flow Manager for User Equipment (UE) in an NR (New Radio) network. It manages the flow of packets for various services within the UE, ensuring that data traffic is efficiently handled in accordance with NR specifications.

This module implements a Packet Flow Manager for User Equipment (UE) within an LTE/NR network. It handles the mapping and management of data packets across different protocol layers, such as PDCP, RLC, MAC, and PHY. The PacketFlowManagerUe ensures that packets are tracked, queued, and processed correctly for transmission and reception, thereby enabling effective communication within the cellular network.

Interface for the PDCP/RRC layer of the LTE Stack.

The LtePdcpRrcBase module implements the functionalities of the Packet Data Convergence Protocol (PDCP). It enables header compression and maps incoming IP packets to different Radio Link Control (RLC) modes. This module dynamically creates LteTxPdcpEntity and LteRxPdcpEntity submodules to handle individual transmission/reception connections

The LtePdcpRrcEnb module implements the PDCP/RRC layer for an LTE NIC employed at eNodeBs. It performs header compression and maps incoming IP datagrams to different Radio Link Control (RLC) modes. Additionally, it supports Dual Connectivity and Split Bearer functionalities.

The LtePdcpRrcEnbD2D module implements the PDCP/RRC layer for a LTE NIC employed at eNodeBs, providing support for D2D (Device-to-Device) communications. This module extends the basic LtePdcpRrcEnb by adding functionality for managing D2D-capable user equipment, specifically for buffering packets during D2D mode switching operations.

The LtePdcpRrcUe module implements the PDCP/RRC layer for an LTE NIC employed at a User Equipment. It performs header compression on incoming IP datagrams

The LtePdcpRrcUeD2D module implements the PDCP/RRC layer for an LTE NIC employed at a User Equipment with support for Device-to-Device (D2D) communications. It extends the basic PDCP/RRC functionality with D2D communication capabilities.

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

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

The NRPdcpRrcEnb module implements the PDCP/RRC layer for a NR NIC utilized at a Base Station. It extends the LtePdcpRrcEnbD2D module to enable Dual Connectivity and Split Bearer functionalities at the eNodeB module.

The NRPdcpRrcUe module implements the PDCP/RRC layer for an NR NIC employed at a User Equipment. It extends the LtePdcpRrcUeD2D module to enable Dual Connectivity and Split Bearer functionalities at the UE.

This module handles the operations related to the NR PDCP (Packet Data Convergence Protocol) layer on the receiving side of a specific connection. It extends the LteRxPdcpEntity module. This 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.

This module handles the operations related to the NR PDCP (Packet Data Convergence Protocol) layer at the transmitting side of a specific connection. It extends the LteTxPdcpEntity module. Additionally, this module manages the creation process by adding support for Dual Connectivity functionality.

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

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

This module extends the LtePhyBase(1,2) 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.

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

This module extends the LtePhyBase(1,2) 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 module extends LTE PHY functionalities at the User Equipment side to support device-to-device (D2D) communications. Specifically, it customizes the LtePhyUe 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.

This module provides the functionalities for the Physical (PHY) layer of the New Radio (NR) protocol stack at the User Equipment (UE) side. In particular, it is responsible for handling the transmission and reception of frames over the radio, as well as the handover procedures when utilizing the NR technology.

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

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.

This module implements the functions for a model representing the 2D channel in the LTE specification 3GPP TR 36.803. It includes the computation of:

This channel model implements path loss, LOS probability, and shadowing according to the following specifications: 3GPP TR 36.873, "Study on 3D channel model for LTE", v12.7.0, December 2017

NRChannelModel_3GPP38_901

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

This is the LTE Uplink Feedback Generator.

The LteRlc module implements the functionalities of the Radio Link Control (RLC) layer. It provides mechanisms for end-to-end connectivity over the radio interface. It sends and receives RLC Service Data Units (SDUs) to and from the Packet Data Convergence Protocol (PDCP) layer, and sends and receives RLC Protocol Data Units (PDUs) to and from the Medium Access Control (MAC) layer. Depending on the mode, this layer can provide segmentation, concatenation, in-sequence delivery, and retransmission of PDUs. Currently, only the Unacknowledged Mode (UM) has been implemented.

This module functions as a (de)multiplexer between the submodules of the LteRlc module (representing the available RLC modes) and the underlying Medium Access Control (MAC) module

This module implements the receiving functionalities of the Acknowledged Mode (AM) of the Radio Link Control (RLC) layer for a specific connection. It stores RLC Protocol Data Units (PDUs) that arrive from the Medium Access Control (MAC) layer and, when possible, performs reassembly and in-sequence delivery of packets to the Packet Data Convergence Protocol (PDCP) layer. It also acknowledges the (un)successful reception of PDUs to the peering AmTxEntity to trigger retransmissions of missing packets and provide guaranteed delivery of packets to the PDCP layer

This module implements the transmitting functionalities of the Acknowledged Mode (AM) of the Radio Link Control (RLC) layer for a specific connection. It stores packets coming from the Packet Data Convergence Protocol (PDCP) layer into a transmission buffer and, upon notification of a transmission opportunity from the Medium Access Control (MAC) layer, sends down a RLC Protocol Data Unit (PDU) of the appropriate size (possibly performing segmentation and/or concatenation). It implements an Automatic Repeat reQuest (ARQ) mechanism to enable the retransmission of unacknowledged RLC PDUs

This module implements the functionalities of the Acknowledged Mode (AM) of the Radio Link Control (RLC) layer. At the transmitting side, it stores packets coming from the Packet Data Convergence Protocol (PDCP) layer into a transmission buffer and, upon notification of a transmission opportunity from the Medium Access Control (MAC) layer, sends down a RLC Protocol Data Unit (PDU) of the appropriate size (via segmentation and/or concatenation). At the receiving side, it stores RLC PDUs arriving from the MAC layer in order to perform reassembly and in-sequence delivery of packets to the PDCP layer. It implements an Automatic Repeat reQuest (ARQ) mechanism to retransmit unacknowledged RLC PDUs at the transmitting side and provide guaranteed delivery at the receiving side.

Receive Buffer of RLC AM

Transmit Buffer of RLC AM

This module implements the functionalities of the Transparent Mode (TM) of the Radio Link Control (RLC) layer.

Interface module for the Unacknowledged Mode (UM) of the Radio Link Control (RLC) layer. It defines gates to the Packet Data Convergence Protocol (PDCP) module and the LteRlcMux module. UM enables segmentation and/or concatenation of RLC Service Data Units (SDUs) before transmission, according to the size of the RLC Protocol Data Unit (PDU) decided by the Medium Access Control (MAC) layer. On the receiving side, RLC SDUs are reassembled before being forwarded to the Packet Data Convergence Protocol (PDCP) layer. In-sequence delivery of RLC SDUs is also guaranteed.

This module implements the functionalities of the Unacknowledged Mode (UM) of the Radio Link Control (RLC) layer. Transmitting- and receiving-side functionalities are provided by the UmTxEntity and UmRxEntity submodules, respectively. The latter are created dynamically whenever a new connection is detected. This module is responsible for identifying the flow to which a RLC Service Data Unit (SDU) or Protocol Data Unit (PDU) belongs and routing it to the corresponding transmitting or receiving entity for further processing.

This module implements the functionalities of the Unacknowledged Mode (UM) of the Radio Link Control (RLC) layer for User Equipments supporting Device-to-Device (D2D) communications. It extends the basic RLC functionalities with specific management functions necessary when a connection is switched from infrastructure mode to D2D mode, and vice versa.

This module implements the receiving-side functionalities of the Unacknowledged Mode (UM) of the Radio Link Control (RLC) layer for a specific connection. It stores RLC Protocol Data Units (PDUs) arriving from the Medium Access Control (MAC) layer and, when possible, performs reassembly and in-sequence delivery of packets to the Packet Data Convergence Protocol (PDCP) layer.

This module implements the transmission side functionalities of the Unacknowledged Mode (UM) of the Radio Link Control (RLC) layer for a specific connection. It stores packets coming from the Packet Data Convergence Protocol (PDCP) layer in a transmission buffer and, upon receiving a notification of a transmission opportunity from the Medium Access Control (MAC) layer, it sends down an RLC Protocol Data Unit (PDU) of the appropriate size (which may involve segmentation and/or concatenation).

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.

This module interface provides the fundamental structure for submodules of the LTE/NR protocol stack that need to interact with the LteX2Manager to utilize X2 communication to accomplish their tasks, such as handover, dual connectivity, and Coordinated Multi-Point.

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

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

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

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