This repository hosts the code required to replicate the findings discussed in our research paper entitled: "A Simulation Study of mmWave 5G-enabled Medical Extended Reality (MXR)" by Tanguy Ropitault, Yongkang Liu, Richard Rouil, and Mohamad Omar Al Kalaa. Our study explores a 5G Medical Extended Reality (MXR) setup, in which a surgeon uses a headset to perform surgeries, leveraging the capabilities of MXR technology. Communication between the Remote Host (RH) and User Equipment (UE) occurs over the Millimeter Wave (mmWave) band. The traffic model used is detailed in this paper and represents a Reduced Function Headset (RFH), also known as remote rendering.
This ns-3 implementation uses three repositories:
- NYU WIRELESS UniPD ns-3 mmWave Module: This repository contains the core version of the ns-3 simulator utilized in our project.
- UniPD ns-3 QD Channel Model: This module enables the integration of the Quasi-Deterministic (Q-D) channel model with ns-3, facilitating high-fidelity mmWave channel representation. The module is located in the
contrib/qd-channelfolder: - PSC NIST: This implementation utilizes the video streaming capability of the PSC module to generate traffic based on a Cumulative Distribution Function (CDF) traffic generator. It supports the creation of RFH (Reduced Function Headset) traffic patterns for Medical Extended Reality (MXR) applications. The video streaming-focused module is located in the
contrib/plcfolder of this repository.
The MXR scenario, implemented in mxr.cc within the scratch folder, features three primary nodes:
- A remote host sending MXR traffic.
- A static 5G Base Station (BS), with 10 different positional scenarios provided.
- The 5G UE, simulating the surgeon's movements and gaze patterns during surgery.
The operational room's 3D model, with dimensions 5.75 m x 5.48 m x 2.8 m, serves as the environment for our simulations. Below is a visualization showing the BS's ten different positions across the scenarios, with stars indicating the surgeon's primary focus points.
Additionally, we simulate the dynamic movements of the surgeon's head, represented by the UE's mobility, to reflect realistic surgical behavior. This includes focusing on the patient, interacting with staff, or consulting medical imagery.
Below is a GIF demonstrating the UE's mobility within an MXR scenario:
The process of generating the MXR scenarios involves several steps, utilizing specific tools and software for mobility modeling and channel realization. Follow these steps to generate and prepare the scenarios for simulation:
-
Mobility Model Generation: Start by generating the mobility model using the MXR Scenario Generator. This tool helps in creating realistic movement patterns for the scenario.
-
Channel Realization: After generating the scenarios, you need to generate the channel realizations for these scenarios using the NIST Q-D Channel Realizations Software. Follow these steps:
- Place the
surgeryScenariosfolder, created by the MXR Scenario Generator, inside thesrc/examplesfolder of the Q-D channel realizations software. - Update the specific line in the
src/main.mfile (found here) to reflect the scenario for which you are generating the channel. - Execute the
src/main.mscript to generate the channel.
- Place the
-
Importing Channel into ns-3:
- Once the channel is generated, import it into ns-3 by copying the generated scenario folders into the
contrib/psc/qd-channel/model/QD/directory of this repository. - The 10 scenarios used in the paper, labeled from
MXRPosition1toMXRPosition10, are already included in this repository for convenience.
- Once the channel is generated, import it into ns-3 by copying the generated scenario folders into the
By following these steps, you can generate and prepare the scenarios needed to reproduce the results presented in the paper.
This repository includes 11 RFH Apps. The first seven (from 1 to 7) correspond to the RFH app discussed in this paper. This paper introduced a CDF distribution to model the traffic observed during measurement campaigns for various use-cases. The remaining four RFH apps simulate higher data rate traffic, such as those used in our paper to represent 4K and 8K traffic, in addition to two apps for 22 Mb/s and 220 Mb/s data rates.
To start the simulation, execute the following command:
./ns3 run "mxr"This command initiates the simulation with the default settings.
This section outlines the parameters available for simulation configuration:
scenario: Specifies the folder containing the Quasi-Deterministic (Q-D) files generated using the NIST Q-D channel software. Valid options include [MXRPosition1, MXRPosition2, MXRPosition3, MXRPosition4, MXRPosition5, MXRPosition6, MXRPosition7, MXRPosition8, MXRPosition9, MXRPosition10]. Default isMXRPosition1.txPower: Defines the transmit power in dBm used by the Base Station (BS) and User Equipment (UE) for transmission. Default value is10 dBm.noiseFigure: Sets the noise figure in dB for both the BS and UE. Default is12 dBm.appStart: The start time of the application in seconds. Default is1 s.appEnd: The end time of the application in seconds. Default is300 s.resultsFolder: Specifies the directory where output traces will be saved. Default isResultsMXR.rfhTraffic: Indicates whether RFH traffic is enabled. Default istrue.rfhAppId: The ID of the RFH App being used. Valid entries are [1, 2, 3, 4, 5, 6, 7, 22Mbps, 220Mbps, 4K, 8K]. Default is1.beamformingInterval: Defines the frequency of beamforming training between the BS and UE in seconds. The default interval is1.codebookFile: Specifies the filename of the codebook to use. Default is1x16.txt.
The simulation generates its results into the directory specified by the resultsFolder parameter, further organized into subdirectories named beamFIntervalX, where X represents the value of the beamformingInterval parameter.
The filenames follow a standard nomenclature: scenario_resultsType_rfh-app-A_txPowerB_runNumberC.txt, where:
scenario: Reflects the value of thescenarioparameter.resultsType: Indicates the type of results, detailed below.A: Represents therfhAppIdparameter value.B: Denotes thetxPowerparameter value.C: Is therunNumberparameter value.
The simulation outputs five types of results, each providing insights into different aspects of the scenario:
-
UE: Logs PHY results at the UE, including the Modulation and Coding Scheme (MCS), number of retransmissions, corruption status, and the Block Error Rate (BLER) of any received packet.
-
Throughput: Records the throughput and Packet Delivery Ratio (PDR).
-
SNR: Documents the Reference Signal Received Power (RSRP) and Signal-to-Interference-plus-Noise Ratio (SINR) as reported by the UE to the BS.
-
Delay: Captures the delay of application traffic received at the UE.
-
Beamforming: Chronicles the beamforming training results between the BS and the UE.

