IdealChannel

Package: ned

IdealChannel

channel

(no description)

Used in compound modules

Name Type Description
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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Upf compound module

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

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.

Used in

Name Type Description
ExtMecAppExample network

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

ExtUeAppExample network

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

ExtUeAppMecAppExample network

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

MultiMecHost network

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

MultiMecHost_delay network

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

MultiOperator network

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

RnisTest network

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

SingleMecHost network

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

UrbanNetwork network (no description)

Properties

Name Value Description
class cIdealChannel

Source code

channel IdealChannel
{
    @class(cIdealChannel);
}

File: Built-in type