Modules¶

Name	Type	Description
AlertReceiver	simple 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.
AlertSender	simple 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.
BackgroundApp	compound 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.
BackgroundCell	compound module	Implements a lightweight model for a 4G eNodeB or 5G gNodeB for generating configurable inter-cell interference in the simulated network.
BackgroundCellChannelModel	simple 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.
BackgroundCellTrafficManager	simple module	Manages the background traffic generated by BackgroundUe in a BackgroundCell.
BackgroundScheduler	simple module	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.
BackgroundTrafficGenerator	compound module	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.
BackgroundTrafficManager	simple module	Manages the background traffic generated by BackgroundUe in a eNodeB or gNodeB.
BackgroundTrafficManagerBase	simple module	This is the base module for the traffic manager for background UEs
BackgroundUe	compound module	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.
BaseStationStatsCollector	compound 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.
BearerConfigurator	simple module	The network’s bearer definitions: the operator’s configuration of the data radio bearers, authored in one place.
BearerManagement	simple module	RRC Bearer Management — creates and tears down PDCP, RLC and MAC entities for data radio bearers.
Binder	simple module	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.
BurstReceiver	simple 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.
BurstSender	simple 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.
CarrierAggregation	compound 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.
CbrReceiver	simple 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.
CbrSender	simple module	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.
CellInfo	simple 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.
CellularNicNdSink	simple module	WORKAROUND: takes what the IPv6 layer of a base station sends to the cellular NIC, which is no interface of the base station’s own network layer: the NIC is wired to the user plane (TrafficFlowFilter, GtpUser), not to the link-layer dispatcher (nl). The NIC stays in the interface table nevertheless, because the address configurator builds the routes of the UEs through it, as their neighbor on the cellular link. The network layer’s dispatcher maps the NIC to this module (see eNodeB), which discards IPv6 Neighbor Discovery messages (Router and Neighbor Solicitations and Advertisements, Redirects): IPv6 runs them on every interface, and they reach no one over the cellular NIC. Any other packet is an error.
ChannelControl	simple module	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.
ChannelModelBase	simple module	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.
ComponentCarrier	simple 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).
ConnectionControlEnb	simple module	The control-plane entry point of a base station: the one module of the node that the control plane of other nodes – the CoreControl, the other base stations, and the UEs’ ConnectionControlUe – talks to, and that the node’s own data path turns to when it needs a bearer.
ConnectionControlEnbD2D	simple module	D2D-capable variant of the ConnectionControlEnb. It adds the sidelink bearers of the UEs the base station serves: a D2D unicast or multicast flow gets a bearer with a fixed transitional configuration (RLC UM on LCG 3), outside the bearer definition system; a multicast bearer’s TX leg is installed at the sender and an RX leg at each group member, and a node joining a group later gets the RX legs of the group’s known senders. The sidelink node pairs’ DRB identities and the established multicast flows are kept network-wide in the D2dBinder, since a sidelink bearer’s ends are UEs whose serving base stations may differ and change.
ConnectionControlUe	simple module	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.
ConnectionControlUeD2D	simple module	D2D-capable variant of the ConnectionControlUe: the leg reports itself D2D-capable when it connects to a base station (if its PHY is), which is where the D2D side of its handovers is handled (ConnectionControlEnbD2D), and a torn-down sidelink bearer’s DRB identity returns to the network-wide sidelink pool (D2dBinder). Selected via ‘connectionControl.typename’ / ‘nrConnectionControl.typename’ by the D2D-capable UE NICs.
CoreControl	simple module	The control plane of the core network, one per cellular network alongside its Binder and BearerConfigurator: the MME and the control plane of the gateways of an EPC, or the AMF and the SMF of a 5G core, in one module.
D2dBinder	simple module	Global holder of the D2D-specific network state, split out of the core Binder.
D2dChannelModel	simple module	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.
D2DModeController	simple module	Controls D2D mode switching flow control.
D2dModeSelectionBase	simple module	Base module for D2D Mode Selection modules.
D2DModeSelectionBestCqi	simple module	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.
DcMux	simple module	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.
DcPdcpLegSplitter	simple module	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.
DcX2Forwarder	simple module	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.
DeviceApp	simple 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.
DrbTable	simple module	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).
eNodeB	compound 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 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 UserPlaneRelay that relays between the NIC and the GTP tunnels: its TrafficFlowFilter classifies incoming packets and determines the next hop, and its GtpUser handles GTP (de)tunneling. Furthermore, it features a configurable number of LteX2App modules to facilitate peer-to-peer communications with other eNodeBs within the same LTE network.
EthernetPortal	simple module	The top of a UE’s cellular NIC when its session is an Ethernet PDU session (the sessionType parameter of LteUe): it makes the NIC an Ethernet port of the UE’s link layer, as INET’s Ethernet interfaces are. Frames of the UE’s link layer (full frames, MAC header and FCS) go down into the NIC’s stack, where the uplink QoS rules classify them and Ip2Nic strips the FCS before SDAP; the downlink frames the NIC delivers up (their FCS rebuilt by Ip2Nic) leave with the receive tags of an Ethernet interface. The link layer’s EthernetLayer ↗ filters them by destination address, unless it is promiscuous (a UE in bridge mode).
EthernetSessionBridge	compound module	The Ethernet bridge of a Upf, which forwards the traffic of its Ethernet PDU sessions “based on detected MAC addresses” (TS 23.501 5.8.2.5.3): one learning bridge per UPF, whose ports are the Ethernet sessions the UPF anchors and one N6 Ethernet interface, the node’s dnEth (TS 23.501 5.8.2.5.3, NOTE 2), which is connected to lowerLayerIn/Out: a submodule of the node, but a port of this bridge, registered in its interface table. A session’s uplink frames enter the bridge on the session’s port; the bridge learns their source addresses, forwards known unicast to the port of the destination (another session: switched locally, not via N6; or dnEth), floods unknown unicast, broadcast and multicast to every port but the ingress, and drops a frame whose destination is on its ingress port. Learning is per VLAN.
EthernetSessionMux	simple module	The bridge’s entry point and multiplexer: creates an EthernetSessionPort per Ethernet PDU session and deletes it at the session’s release (flushing its MAC table entries first), on the calls of the node’s UserPlaneNodeControl; sends each uplink frame of a session (arriving on sessionIn with its SessionTag) to the session’s port, and each frame a port sends down out on sessionOut, tagged with the port’s session.
EthernetSessionPort	compound module	The bridge’s side of one Ethernet PDU session: a port of the EthernetSessionBridge, whose lower side is the session (through EthernetSessionMux). Created and deleted by the mux as the session is established and released.
EthernetSessionPortal	simple module	The inside of an EthernetSessionPort: frames the bridge sends down leave toward the session; frames of the session go up to the bridge as an Ethernet interface delivers them (the receive tags of the port)
EventGenerator	simple module	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.
ExtCell	simple module	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.
FeedbackTester	simple module	(no description)
gNodeB	compound module	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).
GNodeBStatsCollector	compound 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.
GtpUser	simple 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 out on userDataOut: at a base station into the cellular NIC (a base station does not IP-route the UEs’ traffic), at a Upf or PgwStandard onto the data network, unless the destination is a UE of the same core network, whose base station the datagram is then tunneled on to. At a Upf or PgwStandard, userDataOut leads to the node’s message dispatcher, and every packet carries the service it is for (DispatchProtocolReq): ipv4/ipv6 for the data network, ethernetmac for the EthernetSessionBridge, and icmpv6 for the Ipv6NdResponder, which gets the link-local traffic of the UEs’ IPv6 sessions, each packet tagged with its session (the IP link of a session ends at its anchor, and its Neighbor Discovery must not leak onto the data network). Resides, with the TrafficFlowFilter, in the UserPlaneRelay of every node that ends GTP-U tunnels: eNodeB, gNodeB, PgwStandard and Upf (also as the UPF of a MecHost).
GtpUserX2	simple 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.
HandoverPacketHolderEnb	simple module	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.
HandoverPacketHolderUe	simple module	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.
HandoverX2Forwarder	simple module	Forwards the downlink a handover source holds for a UE leg to the target base station over X2-U, and delivers what arrives from a source to this node’s HandoverPacketHolderEnb: the data forwarding of the handover, between the source’s and the target’s packet holders, through the LteX2Manager. The handover’s signaling is the base stations’ control plane’s (ConnectionControlEnb).
IdealChannelModel	simple module	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.
Ip2Nic	simple module	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.
Ip2NicD2D	simple module	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.
Ipv6NdResponder	simple module	Answers the IPv6 Neighbor Discovery traffic of the UEs’ sessions at the session anchor (Upf, PgwStandard), which is the router on the IP link of an IPv6 session: the base station is transparent to it. In 5GS the SMF generates the Router Advertisements and the UPF relays them into the session’s tunnel, together with the UE’s Router Solicitations the other way (TS 23.502); this module stands in for both.
LocationService	simple 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.
LteAmc	simple module	LTE Adaptive Modulation and Coding (AMC) module.
LteAmcD2D	simple module	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.
LteCar	compound module	Defines a LteCar node as a LTE User Equipment (UE) with vehicular-like mobility. This behavior is modeled by utilizing the Veins-Inet project.
LteChannelControl	simple module	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.
LteCompManagerBase	simple module	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.
LteCompManagerProportional	simple module	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.
LteDlFeedbackGenerator	simple module	This is the Lte Downlink Feedback Generator. It manages periodic and aperiodic channel sensing and feedback transmission.
LteMacBase	compound module	Base module for the Medium Access Control (MAC) layer of the LTE protocol stack.
LteMacEnb	compound module	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.
LteMacEnbD2D	compound 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).
LteMacUe	compound module	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.
LteMacUeD2D	compound 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.
LteNicBase	compound module	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.
LteNicEnb	compound module	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.
LteNicEnbD2D	compound module	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.
LteNicUe	compound module	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.
LteNicUeD2D	compound 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.
LtePdcpEntity	compound module	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.
LtePdcpRxEntity	simple 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.
LtePdcpTxEntity	simple 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.
LteRlcAmEntity	compound module	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.
LteRlcAmRxEntity	simple module	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.
LteRlcAmTxEntity	simple module	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.
LteRlcUmEntity	compound module	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.
LteRlcUmEntityD2D	compound module	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.
LteRlcUmRxEntity	simple module	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).
LteRlcUmRxEntityD2D	simple module	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.
LteRlcUmTxEntity	simple module	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.
LteRlcUmTxEntityD2D	simple module	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).
LteSchedulerEnbDl	simple module	LTE eNB downlink scheduler module.
LteSchedulerEnbUl	simple module	LTE eNB uplink scheduler module.
LteSchedulerEnbUlD2D	simple module	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.
LteUe	compound 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. The UE is an INET StandardHost ↗ with the cellular NIC as an additional network interface of its link layer, so it has all the higher layers of the protocol stack, from the link layer to the application modules, and the configuration options of StandardHost ↗ (numApps, hasUdp, hasTcp, hasIpv4, hasIpv6, numEthInterfaces, etc.). Its Ethernet interfaces (eth[]) are utilized in real-time emulation mode to connect the UE to the real network (outside the simulator) via a virtual Ethernet interface.
LteUlFeedbackGenerator	simple module	This is the LTE Uplink Feedback Generator.
LteX2App	compound 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:
LteX2Manager	simple 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). 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.
MecAppBase	simple module	This is a MEC app that … TBC
MecHost	compound 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.
MecOrchestrator	simple 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.
MecPlatform	compound 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.
MecPlatformManager	simple 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.
MecRequestBackgroundApp	simple module	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)
MecRequestBackgroundGeneratorApp	simple module	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)
MecRequestForegroundApp	simple 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.
MecResponseApp	simple 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.
MecRnisTestApp	simple module	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.
MecRTVideoStreamingReceiver	simple module	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.
MecWarningAlertApp	simple module	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.
MultihopD2D	simple module	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:
MultihopD2DStatistics	simple module	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.
MultiUeMecApp	simple module	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
NrAmc	simple module	NR Adaptive Modulation and Coding (AMC) module.
NrAmcD2D	simple module	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.
NrCar	compound module	Defines a LteCar node as an NR User Equipment (UE) with vehicular-like mobility. The latter is modeled by utilizing the Veins-Inet project.
NrMacGnb	compound 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 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.
NrMacGnbD2D	compound module	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.
NrMacUe	compound 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.
NrMacUeD2D	compound module	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.
NrNicEnb	compound module	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.
NrNicEnbD2D	compound module	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.
NrNicUe	compound module	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.
NrNicUeD2D	compound module	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.
NrPacketFlowObserverGnb	simple 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.
NrPacketFlowObserverUe	simple 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.
NrPdcpEntity	compound module	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).
NrPdcpRxEntity	simple 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 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.
NrPdcpTxEntity	simple 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 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).
NrRlcAmEntity	compound module	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.
NrRlcAmRxEntity	simple module	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.
NrRlcAmTxEntity	simple module	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.
NrRlcUmEntity	compound module	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.
NrRlcUmEntityD2D	compound module	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.
NrRlcUmRxEntity	simple module	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.
NrRlcUmRxEntityD2D	simple module	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.
NrRlcUmTxEntity	simple module	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.
NrRlcUmTxEntityD2D	simple module	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.
NrSchedulerGnbUl	simple module	NR gNB uplink scheduler module.
NrSchedulerGnbUlD2D	simple module	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.
NrSdap	simple module	Implements the SDAP Protocol.
NrUe	compound module	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.
NrUeStatsCollector	compound 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.
PacketFlowObserverEnb	simple 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.
PacketFlowObserverUe	simple 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.
PdcpDownlinkRelay	simple module	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.
PdcpEntityBase	compound module	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.
PdcpLegJoiner	simple module	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).
PdcpMux	simple module	Upper-layer PDCP packet dispatcher.
PdcpRelayEntity	compound module	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.
PdcpUplinkRelay	simple module	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.
PgwStandard	compound module	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 UserPlaneRelay, whose GtpUser handles GTP (de)tunneling and whose TrafficFlowFilter classifies incoming packets.
PhyBase	simple module	Base module for the Physical (PHY) layer of the LTE/NR protocol stack.
PhyEnb	simple module	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.
PhyEnbD2D	simple module	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.
PhyUe	simple module	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.
PhyUeD2D	simple module	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.
QosFlowClassifier	simple module	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.
ReflectiveQosTable	simple module	ReflectiveQosTable maintains a table of QoS flow mappings for reflective QoS.
Registration	simple module	RRC Registration — registers the node with the Binder, sets up the network interface, and joins multicast groups.
RlcAmEntityBase	compound module	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.
RlcMux	simple module	Lower-layer RLC packet dispatcher.
RlcMuxD2D	simple module	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.
RlcTmEntity	compound module	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.
RlcTmRxEntity	simple module	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.
RlcTmTxEntity	simple module	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.
RlcUmEntityBase	compound module	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.
RniService	simple 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.
Rrc	compound module	RRC (Radio Resource Control) layer for LTE/NR networks.
RrcD2D	compound 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.
RtVideoStreamingSender	simple module	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.
ServiceRegistry	simple 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
SocketManager	simple module	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.
StochasticChannelModel	simple module	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.
Tr36873ChannelModel	simple module	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.
Tr38901ChannelModel	simple module	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.
TrafficFlowFilter	simple module	Maps IP 4-Tuples to Traffic Flow Template (TFT) identifiers, which are used by the GtpUser module next to it. It interacts with the Binder to determine the destination of the packet. Resides, with the GtpUser, in the UserPlaneRelay of every node that ends GTP-U tunnels: eNodeB, gNodeB, PgwStandard and Upf (also as the UPF of a MecHost). 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). In a base station, it receives the UEs’ uplink datagrams straight from the cellular NIC.
TrafficGeneratorBase	simple 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.
TrafficGeneratorCbr	simple 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.
TrafficLight	compound 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.
TrafficLightController	simple 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.
TrafficLightMobility	simple 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.
Ualcmp	compound 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.
UalcmpApp	simple 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:
UeRequestApp	simple module	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.
UeRnisTestApp	simple module	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
UeStatsCollector	compound 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.
UeWarningAlertApp	simple module	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.
UnstructuredApp	compound module	An application of a UE whose session is of type Unstructured (the UE’s sessionType parameter, see LteUe): it sends and receives opaque payload through the UE’s cellular NIC, which carries it over the session to the data network (see UserPlaneNodeControl for the N6 end of the session). The traffic source and sink are built from queueing model elements, as INET’s EthernetApp’s; UnstructuredIo attaches them to the NIC. UnstructuredSourceApp and UnstructuredSinkApp only send and only receive. A UE has at most one such application, in its unstructuredApp submodule vector.
UnstructuredIo	simple module	Attaches an application to the cellular NIC of a UE whose session is of type Unstructured (the UE’s sessionType parameter, see LteUe): the payload goes down to the NIC and comes up from it as is, with no transport or network layer in between. Packets arriving on trafficIn are sent to the NIC tagged with the “unstructured” protocol; what the NIC delivers up as that protocol leaves on trafficOut. The module registers as the node’s receiver of the protocol, so a UE has at most one of it. It is connected to the UE’s network-layer dispatcher (see the unstructuredApp submodules of LteUe).
UnstructuredSinkApp	compound module	An UnstructuredApp that only receives
UnstructuredSourceApp	compound module	An UnstructuredApp that only sends
Upf	compound module	Implements the 5G Core User Plane Function (UPF).
UserPlaneNodeControl	simple module	The control-plane entry point of a user plane node (Upf, PgwStandard, a MEC host’s UPF): the node’s end of the interface over which the core network’s control plane (CoreControl) programs the user plane – N4 with PFCP (TS 29.244) in a 5G core; in an EPC, GTP-C over S11/S5 (TS 29.274), or Sx with PFCP under CUPS. The signaling is not modeled as packets; it is modeled as the calls this module answers:
UserPlaneRelay	compound module	The user-plane relay of a node that ends GTP-U tunnels: the “relay” between the two protocol stacks in the user-plane stack diagrams of 3GPP (TS 23.401, 23.501, 38.300). At a base station it relays between the radio interface and the N3/S1-U tunnels, at a Upf or PgwStandard between the data network (N6/SGi) and the tunnels toward the base stations or other UPFs.
VirtualisationInfrastructure	compound 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.
VirtualisationInfrastructureManager	simple module	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.
VodUdpClient	simple 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.
VodUdpServer	simple 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.
VoipReceiver	simple 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.
VoipSender	simple 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.
X2AppClient	simple 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.
X2AppServer	simple 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.