COEmuNet: Dual Emulation Systems

• COEmuNet is a term that denotes two distinct emulation systems: one coupling real smartphones with simulated pedestrian networks and the other using a 3D CNN to surrogate astrophysical radiative transfer.
• In the pedestrian domain, COEmuNet integrates mobility simulators with network emulation platforms like OMNeT++ and Vadere to enable real-time interaction between simulated entities and physical devices.
• In astrophysics, COEmuNet employs GPU-accelerated deep learning to approximate complex radiative transfer calculations, achieving significant speedups over traditional CPU-based solvers.

Searching arXiv for COEmuNet to ground the response in the cited literature. arxiv_search(query="COEmuNet", max_results=10, sort_by="submittedDate") COEmuNet denotes two distinct research systems that share the same name but belong to different technical domains. In networked pedestrian simulation, COEmuNet is the open-source CrowNet Emulation extension that couples microscopic pedestrian mobility with OMNeT++ network emulation so that simulated pedestrians can communicate with, and be influenced by, real mobile devices and apps in real time (Rupp et al., 2021). In computational astrophysics, COEmuNet is a 3D convolutional neural network surrogate that emulates CO line radiative transfer for synthetic observations of evolved stellar atmospheres, specifically CO $J=2 \rightarrow 1$ imaging from hydrodynamical simulations of perturbed Asymptotic Giant Branch winds (Su et al., 15 Jul 2025). The shared label therefore identifies two unrelated artifacts: one in cyber-physical network emulation, the other in GPU-accelerated surrogate modeling for radiative transfer.

1. Nomenclature and domain separation

The term has two established meanings in the cited literature.

COEmuNet variant	Domain	Core function
CrowNet Emulation extension	Pedestrian communication and network emulation	Couples Vadere-based microscopic mobility with OMNeT++ emulation and real smartphones
3D CNN surrogate model	Astrophysical radiative transfer	Emulates forward CO $J=2 \rightarrow 1$ line imaging from 3D hydrodynamical inputs

A common misconception is to treat COEmuNet as a single framework with multiple application areas. The literature instead uses the same name for two independent systems with different assumptions, software stacks, data models, and evaluation criteria. One is centered on OMNeT++, INET, TraCI, Vadere, and SimuLTE for real-time interaction with smartphones; the other is centered on 3D residual CNNs, hydrodynamical simulation cubes, and a classical radiative transfer solver, Pomme, used to generate training labels (Rupp et al., 2021, Su et al., 15 Jul 2025).

2. COEmuNet as a CrowNet emulation extension

Within the CrowNet ecosystem, COEmuNet extends a framework that historically integrates mobility simulators such as Vadere and SUMO with OMNeT++ communication models including INET, Artery, and SimuLTE/Simu5G via TraCI for synchronized co-simulation (Rupp et al., 2021). The extension adds an emulation bridge that injects packets from real devices, received on the emulation PC’s WLAN interface, into the simulated network stack so that simulated pedestrians can hear and react to real transmissions. It also exports simulated node states, especially positions, to the real device, allowing an app to operate as if it were moving in the simulated world without physical movement. When desired, it lets the real device drive the simulated placeholder’s position, thereby closing the loop between app and simulation.

The physical setup consists of one or more smartphones connected through local WLAN to an emulation PC running OMNeT++ and CrowNet. The PC captures UDP/IP/WLAN packets from the phones, maps them to simulated entities, and forwards simulated messages back to the phones. The paper assumes that the extra WLAN delay is negligible compared to the modeled communication delays. On the simulated side, pedestrian nodes use a standard OMNeT++ stack with BeaconApp for periodic position beacons, DensityMapApp for periodic dissemination of density maps, and udp, ipv4, and lteNic for LTE-A sidelink broadcast over PC5. The coupled real device is represented by an emulation bridge node, denoted node[0], whose application layer hosts OutboundEmulation, NodeLocationExporter, and InboundEmulation.

OutboundEmulation converts simulated beacons and maps into Protocol Buffers for the app and sends them via inet::ExtLowerUdp over the real network. Its DensityMessageHandler serializes position beacons into the app’s protobuf format. NodeLocationExporter exports node[0]’s simulated position through inet::ExtLowerUdp so that the app’s location can be controlled by Vadere. InboundEmulation receives protobuf location beacons from the app and sets node[0]’s simulated position accordingly. The emulation mechanism relies on OMNeT++’s emulation feature, specifically INET’s inet::ExtLowerUdp and a real-time scheduler, to bind sockets to the host operating system so that packets traverse the real WLAN.

3. Mobility coupling, decentralized density maps, and timing behavior

COEmuNet integrates Vadere as the pedestrian mobility provider via TraCI, using the Optimal Steps Model with navigation fields encoding shortest geodesic paths to targets while modeling each step (Rupp et al., 2021). CrowNet’s TraCI-based co-simulation interlocks the simulation loops of Vadere and OMNeT++, and this synchronization is harmonized by Artery’s TraCI connection management for both SUMO and Vadere. Because inet::ExtLowerUdp requires OMNeT++ to run in real-time mode, inet::RealTimeScheduler keeps $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$. A custom crownet::EmulationScheduler re-aligns simulation time to wall clock after Vadere attaches and provides timing analysis utilities to monitor the offset $t_{\mathrm{real}} - t_{\mathrm{sim}}$.

The exemplar application is Decentralized Pedestrian Density Maps. Each device builds a local two-dimensional density map from periodic position beacons and rebroadcasts this map so neighbors can fuse their views into a decentralized larger-area awareness map. Beacons are LocationMessage payloads encoded in Protocol Buffers with device ID, timestamp, and position in UTM coordinates. Positions originate from Android Location Services in WGS84 and are converted to UTM for grid indexing. The map is a rectangular occupancy grid with typical cell size $3\,\mathrm{m} \times 3\,\mathrm{m}$, each cell identified by the UTM coordinates of its top-left corner. Devices accumulate counts from received beacons into their local grid and periodically rebroadcast their map. The paper does not specify a particular estimator or log-odds formulation; aggregation is count-based with periodic re-broadcast and smoothing left to the application.

Two coupling modes are provided. In simulation-driven positioning, NodeLocationExporter causes Vadere to drive the positions of both simulated pedestrians and node[0], so the app experiences simulation-controlled motion without physically moving the phone. In phone-driven positioning, InboundEmulation lets the app report its position so that node[0] follows the real device’s movement while other simulated pedestrians still follow Vadere.

Validation focuses on timing feasibility under real-time constraints. The testbed was a low-end Ubuntu VM with 2 CPU cores and 12 GB RAM, running CrowNet and OMNeT++ with one eNodeB and $n = 4 \ldots 8$ pedestrians or UEs. Both $t_{\mathrm{real}}$ and $t_{\mathrm{sim}}$ were sampled at 10 ms intervals, and the offset $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$ was analyzed. Synchronized emulation was feasible up to $n \approx 6$ on the test machine; for $J=2 \rightarrow 1$0, $J=2 \rightarrow 1$1 exceeded 5 s. Even for $J=2 \rightarrow 1$2, occasional multi-second lags occurred, although in the presented use-case lags of $J=2 \rightarrow 1$3 were regarded as acceptable. The reported bottleneck is event load from the number of simulated nodes, including radio stack processing, mobility updates, and application logic. The paper does not provide CPU usage, throughput, or jitter figures; $J=2 \rightarrow 1$4 is the primary timing metric.

The communication and mobility parameterization in the pedmap_emulation configuration includes $J=2 \rightarrow 1$5, $J=2 \rightarrow 1$6, $J=2 \rightarrow 1$7, $J=2 \rightarrow 1$8, carrier frequency $J=2 \rightarrow 1$9, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$0 resource blocks, ITU-R M.2135-1 URBAN-MICROCELL pathloss, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$1, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$2, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$3, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$4, RLC unacknowledged mode, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$5, $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$6, and mobility bounds $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$7.

4. COEmuNet as a radiative transfer surrogate model

In astrophysics, COEmuNet addresses a different bottleneck: the high computational cost of 3D line radiative transfer in inhomogeneous, moving media when interpreting asymmetric structures around companion-perturbed AGB stars (Su et al., 15 Jul 2025). The model is a GPU-accelerated 3D CNN surrogate for CO $t_{\mathrm{sim}} \approx t_{\mathrm{real}}$8 line imaging that emulates the forward radiative-transfer mapping from hydrodynamical fields to synthetic line images in right ascension, declination, and frequency.

The radiative-transfer problem is formulated through the scalar equation

$t_{\mathrm{sim}} \approx t_{\mathrm{real}}$9

with source function $t_{\mathrm{real}} - t_{\mathrm{sim}}$0 and optical depth

$t_{\mathrm{real}} - t_{\mathrm{sim}}$1

The integral solution is

$t_{\mathrm{real}} - t_{\mathrm{sim}}$2

The paper’s time-independent, no-scattering vector notation is

$t_{\mathrm{real}} - t_{\mathrm{sim}}$3

with formal solution along the observer axis $t_{\mathrm{real}} - t_{\mathrm{sim}}$4:

$t_{\mathrm{real}} - t_{\mathrm{sim}}$5

For the $t_{\mathrm{real}} - t_{\mathrm{sim}}$6 transition, the emissivity and opacity are

$t_{\mathrm{real}} - t_{\mathrm{sim}}$7

with

$t_{\mathrm{real}} - t_{\mathrm{sim}}$8

The line profile is Gaussian,

$t_{\mathrm{real}} - t_{\mathrm{sim}}$9

with Doppler width

$3\,\mathrm{m} \times 3\,\mathrm{m}$0

The implementation uses the line-of-sight velocity $3\,\mathrm{m} \times 3\,\mathrm{m}$1, giving $3\,\mathrm{m} \times 3\,\mathrm{m}$2. Training labels are generated assuming LTE and no scattering, with level populations

$3\,\mathrm{m} \times 3\,\mathrm{m}$3

The paper explicitly notes that COEmuNet itself does not embed LTE; it learns the mapping induced by labels produced under LTE and no scattering.

The model input is a Cartesian hydrodynamical cube $3\,\mathrm{m} \times 3\,\mathrm{m}$4 on a $3\,\mathrm{m} \times 3\,\mathrm{m}$5 grid for three fields: $3\,\mathrm{m} \times 3\,\mathrm{m}$6 in $3\,\mathrm{m} \times 3\,\mathrm{m}$7, $3\,\mathrm{m} \times 3\,\mathrm{m}$8 in K, and $3\,\mathrm{m} \times 3\,\mathrm{m}$9 in $n = 4 \ldots 8$0. Viewing direction $n = 4 \ldots 8$1 is handled by preprocessing: the cube is rotated so that the desired $n = 4 \ldots 8$2 aligns with the solver’s $n = 4 \ldots 8$3-axis, with auxiliary spherical cropping to maintain a consistent domain after rotation. The output is a set of synthetic CO $n = 4 \ldots 8$4 intensity images across $n = 4 \ldots 8$5 frequency bins centered at $n = 4 \ldots 8$6, with bin width $n = 4 \ldots 8$7, on a $n = 4 \ldots 8$8 image grid.

5. Neural architecture, data pipeline, and quantitative evaluation

The network uses an asymmetric encoder-decoder design motivated by the fact that the inputs are physical 3D fields whereas the outputs are 2D images across frequencies, so there is no pixelwise spatial correspondence of the kind commonly exploited by U-Nets (Su et al., 15 Jul 2025). The encoder has three branches, one per input field $n = 4 \ldots 8$9, $t_{\mathrm{real}}$0, and $t_{\mathrm{real}}$1. Each branch contains stacks of 3D convolutional residual blocks with kernel size $t_{\mathrm{real}}$2, Batch Normalization, and ReLU activations. Skip connections are identities when feature dimensions match and otherwise use a $t_{\mathrm{real}}$3 convolutional skip. Channel widths progress from 8 to 16 to 32, while spatial downsampling reduces $t_{\mathrm{real}}$4 to $t_{\mathrm{real}}$5, then $t_{\mathrm{real}}$6, then $t_{\mathrm{real}}$7. Encoded tensors are concatenated, flattened, passed through two fully connected layers, and reshaped into a 3D latent tensor. The decoder upsamples progressively using nearest-neighbor interpolation, followed by 3D convolutions with kernel size $t_{\mathrm{real}}$8. Feature widths decrease from 32 to 16 to 8 while spatial resolution increases from $t_{\mathrm{real}}$9 to $t_{\mathrm{sim}}$0, $t_{\mathrm{sim}}$1, $t_{\mathrm{sim}}$2, and finally $t_{\mathrm{sim}}$3. A final convolution maps to the $t_{\mathrm{sim}}$4 output channels. No attention modules are used.

Input preprocessing standardizes $t_{\mathrm{sim}}$5 as

$t_{\mathrm{sim}}$6

while $t_{\mathrm{sim}}$7 and $t_{\mathrm{sim}}$8 are transformed by logarithm and robust normalization:

$t_{\mathrm{sim}}$9

with the same transformation for $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$0. Targets undergo log transform and min-max scaling.

The training set is derived from AMRVAC/MPI-AMRVAC simulations of winds from a mass-losing AGB star perturbed by a companion. Radiative-transfer labels are computed by Pomme, consistent with LTE and no scattering, using constants from LAMDA. The dataset contains 10,903 hydrodynamical models and 200 viewing directions per model, yielding $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$1 samples. The split is 80% train, 10% validation, and 10% test. Total volume is approximately 7 TB, so preprocessing is chunk-wise, with CPU RAM preloading, GPU/CPU overlap, and multi-threaded prefetching through PyTorch dataloaders.

The loss is a weighted sum of mean-squared error and a frequency-domain $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$2 term based on per-channel DFT magnitude differences:

$\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$3

with $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$4 selected by grid search. Pretraining for the face-on, single-frequency case uses Adam with $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$5, $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$6, learning rate $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$7, StepLR decay by 0.1 every 200 epochs, batch size 512 across $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$8 A100-SXM-80GB GPUs, and 1000 epochs, for approximately 8 GPU-hours total. Fine-tuning for seven frequencies and arbitrary $\Delta t = t_{\mathrm{real}} - t_{\mathrm{sim}}$9 uses Adam with fixed learning rate $n \approx 6$0, no scheduler, global batch size 2048, and 100 epochs, for approximately 288 GPU-hours total. No explicit dropout or weight decay is used; early stopping around epoch 50–60 is recommended because losses and metrics plateau there.

Evaluation is reported through MaxRel, ZNCC, SSIM, and a median relative error notion summarized in the paper as approximately 7%. On the test set, the reported aggregate values are MaxRel $n \approx 6$1, ZNCC $n \approx 6$2, and SSIM $n \approx 6$3. On the validation set, the mean MaxRel is approximately $n \approx 6$4 with $n \approx 6$5; $n \approx 6$6 of samples have MaxRel $n \approx 6$7, $n \approx 6$8 exceed $n \approx 6$9, $J=2 \rightarrow 1$00 exceed $J=2 \rightarrow 1$01, and the worst case is approximately $J=2 \rightarrow 1$02. Errors are lowest near line center and increase in central regions with sharp intensity gradients and in complex spiral arms at high velocities.

Runtime comparisons on $J=2 \rightarrow 1$03 images show the principal acceleration claim. For a single frequency, COEmuNet on an A100-80GB GPU takes $J=2 \rightarrow 1$04 ms per sample, while Pomme on an Intel Xeon Platinum 8368Q CPU takes $J=2 \rightarrow 1$05 ms, corresponding to a speedup of $J=2 \rightarrow 1$06. For seven frequencies, COEmuNet takes $J=2 \rightarrow 1$07 ms per sample and Pomme takes $J=2 \rightarrow 1$08 ms, corresponding to $J=2 \rightarrow 1$09 speedup. The paper also reports that CPU inference for COEmuNet, $J=2 \rightarrow 1$10 ms per sample, is slower than Pomme because the network’s tensor operations favor GPU parallelism.

6. Limitations, reproducibility, and relation to adjacent work

The pedestrian-network COEmuNet is explicitly a feasibility study with strong real-time constraints (Rupp et al., 2021). Its practical scale on the reported low-end VM is about six simulated pedestrians under coupled emulation. Real-device coupling currently relies on UDP/IP over WLAN broadcast because commercial phones do not yet expose LTE-A PC5, so WLAN acts as a temporary surrogate for app validation. The paper identifies parallel execution and model simplifications as plausible requirements for larger scenarios and states that an upgrade to 5G with Simu5G is planned for more realistic sidelink and MEC emulation. Dependencies include OMNeT++ 6.0 preview 11, INET 4.3.2, Vadere via TraCI, Artery for TraCI management, and SimuLTE, with example scenario files under crownet/simulations/emulation_omnetsummit21 and source code at https://github.com/roVer-HM/crownet/tree/emulation_omnetsummit21.

The astrophysical COEmuNet inherits the biases of its training labels (Su et al., 15 Jul 2025). The labels assume LTE and exclude scattering; the paper notes that LTE is known to be imperfect for circumstellar CO. The model is tuned to binary-perturbed AGB winds, the CO $J=2 \rightarrow 1$11 transition, seven frequency bins, and fixed $J=2 \rightarrow 1$12 input resolution. Generalization to other molecules, transitions, disks, single-star winds, substantially different resolutions, or different noise conditions is not established and would likely require retraining or fine-tuning. Metrics are not stratified by optical-depth regime, and no explicit predictive uncertainty or calibration is reported. Future directions include non-LTE training labels, additional molecules and transitions, physics-informed machine learning constraints, Bayesian neural nets or ensembles for uncertainty quantification, active learning, and multi-resolution operator-style models. Reproducibility resources include a repository at https://github.com/beaversliv/3D_RTE_surrogate_model, while hydrodynamical inputs and radiative-transfer labels are available upon reasonable request to the corresponding author.

Both systems are situated relative to adjacent frameworks, but in different literatures. The CrowNet emulation extension is distinguished from ns-3 emulation and LENA LTE setups by its focus on pedestrian-centric applications with validated microscopic pedestrian mobility, from Similitude by its use of real phones rather than Android emulators, from Veins by its pedestrian rather than vehicular mobility and its real-device emulation bridge, and from Mininet-WiFi by its integration of microscopic pedestrian mobility with OMNeT++ system-level LTE or 5G models (Rupp et al., 2021). The astrophysical COEmuNet is positioned against classical CPU-oriented radiative-transfer solvers such as Pomme, which remain accurate but become bottlenecks for large parameter sweeps, repeated fitting, or interactive visualization (Su et al., 15 Jul 2025).

Taken together, the two COEmuNet systems exemplify a naming collision rather than a shared research program. One couples real smartphones to simulated pedestrian networks under real-time scheduling; the other replaces repeated radiative-transfer solves with a learned forward surrogate. A plausible implication is that the common name reflects a broad notion of “emulation,” but the underlying semantics differ sharply: network-system emulation in one case, and learned emulation of a physical forward model in the other.