Aerial Omniverse Digital Twin PDF

Aerial Omniverse Digital Twin Table of contents Aerial Omniverse Digital Twin - User Guide 8 Aerial Omniverse Digital Twin 1 List of Figures Figure 0. System Figure 1. Button As Worker Figure 2. Ov Auth Figure 3. Install Open Tokyo Figure 4. Install Add Panel Figure 5. Install Add Ru Figure 6. Install Place Ru Figure 7. Install Edit Ru Figure 8. Install Add Ue Figure 9. Button As Mobi Figure 10. Button As Play Figure 11. Install Ray Paths Figure 12. Interface Figure 13. Ui Conﬁguration Figure 14. Ui Ant El Figure 15. Ru Figure 16. Ue Figure 17. Layers Figure 18. Button As Worker Aerial Omniverse Digital Twin 2 Figure 19. Button As Mobi Figure 20. Button As Play Figure 21. Button As Pause Figure 22. Button As Stop Figure 23. Button As Refresh Figure 24. Attach Worker Error Window Figure 25. Mobi Worker Locked Figure 26. Mobi Worker Unlocked Figure 27. Antenna Panel Property Widget Figure 28. Ue Edit Waypoints Property Widget Figure 29. Drawing Ue Manual Waypoints Figure 30. Spawn Zone Bounding Box Figure 31. Scale Rotate Move Widget Figure 32. Camera View Figure 33. Sim Progress Bar Figure 34. Show Raypaths Figure 35. Simulate Ran Figure 36. UE Thr Figure 37. UE Thr2 Figure 38. UE MCS Figure 39. Scheduler Aerial Omniverse Digital Twin 3 Figure 40. Building Edge Data Figure 41. CFRs Mem Arrangement Aerial Omniverse Digital Twin 4 List of Tables Table 0. Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. Table 10. Table 11. Table 12. Table 13. Table 14. Table 15. Table 16. Table 17. Table 18. Aerial Omniverse Digital Twin 5 Table 19. Table 20. Table 21. Table 22. Table 23. Table 24. Table 25. Table 26. Aerial Omniverse Digital Twin 6 Aerial Omniverse Digital Twin - User Guide Overview System requirements Installation Graphical user interface Scene importer RAN digital twin Appendix Aerial Omniverse Digital Twin 7 Aerial Omniverse Digital Twin - User Guide Changelog Revision Date Changes 1.0.0 4/19/2024 First release Overview The Aerial Omniverse Digital Twin consists of the following components: User interface ClickHouse Omniverse Nucleus Scene importer RAN digital twin interconnected as illustrated in the following ﬁgure. Aerial Omniverse Digital Twin 8 User interface The graphical interface oﬀers the possibility of visualizing and interacting with the scenario, as well as parametrizing, starting, interrupting and stopping simulations. ClickHouse The results produced by the Aerial Omniverse Digital Twin are stored in an SQL database hosted by the ClickHouse server. Correspondingly, they can be access through ClickHouse clients. Nucleus The Nucleus server delivers message brokering services and provisions the scene geometry to the other components. In all cases, the Nucleus server needs to be on a node whose IP address can be reached by the other components. This requires having the ports described here open. Scene importer The Nucleus server stores and distributes the scene geometry in the OpenUSD format. The scene importer takes in geospatial data in CityGML format and creates the OpenUSD assets needed by the Nucleus server to represent a given scene. RAN digital twin Aerial Omniverse Digital Twin 9 The actual radio access network (RAN) digital twin is in charge of updating the positions of a population of terminals, scheduling the transmission of data from all of the deployed radio units to all of the terminals, computing the channel frequency response for all of the links - where a link is here intended as a wireless connection between two antenna elements - described in the scene under investigation, generating the waveforms at the transmission point of every link, applying the calculated frequency response, interference and noise to said waveforms, thus creating the ﬁnal signal observed at the reception point of every link, applying the necessary signal processing to extract and decode the transmitted data. System Requirements Aerial Omniverse Digital Twin (AODT) can be installed in the cloud or on-prem. The installation and operation of AODT involves deploying a set of frontend components and a set of backend components. The frontend components require one NVIDIA GPU, and the backend components require another NVIDIA GPU. The frontend components and backend components can be deployed to either the same node (i.e., colocated) or to separate nodes (i.e. multi-node). The following table details the GPU requirements for each case: GPU GPU GPU GPU System Type GPU Notes Qnty Driver vRAM Requirement e.g. RTX 6000 Ada, A10, Frontend alone 1 r535+ 12GB+ GTX/RTX L40 e.g. RTX 6000 Ada, Backend alone 1 r535+ 48GB+ A100, H100, L40 Frontend and see 1x frontend-capable 2 r535+ see note backend colocated note GPU, 1x backend GPU The following table describes the OS support for each type: Aerial Omniverse Digital Twin 10 System Type OS Frontend alone Windows 11, Windows Server 2022, Ubuntu 22.04 Backend alone Ubuntu 22.04 Frontend and backend colocated Ubuntu 22.04 For memory and CPU requirements, we recommend looking at the qualiﬁed systems in the next section. Installation The AODT Installer is a way to get up and running quickly with fresh installations on qualiﬁed systems, both in the cloud and on-prem. There are several components that must be installed and conﬁgured in order for a deployed system to run AODT. This section will detail how to use the AODT Installer on each of the qualiﬁed system conﬁgurations. Following those instructions will be more general guidelines to help with installations for other system conﬁgurations. Qualiﬁed deployment targets The following qualiﬁed systems have been tested and are directly supported with the AODT Installer: Qualiﬁed system Node 1 Node 2 Backend Node Frontend Node Standard_NC24a Standard_NV36ads_A10_v5 ds_A100_v4 Windows Server 2022 Ubuntu Server Omniverse Enterprise Virutal Azure VM (Multi- 22.04 Workstation - version 1.0 - x64 Gen 2 Node) NVIDIA A100 NVIDIA A10 GPU GPU 36 vcpus 24 vcpus Memory 440GB Memory 220GB Dell R750 (Coloc Colocated N/A ated) Ubuntu 22.04 - Server Intel Xeon Gold 6336Y 2.4G, 24C/48T PCIe Gen4 2x NVIDIA RTX 6000 Ada GPU Aerial Omniverse Digital Twin 11 Memory 512GB DDR4 Storage 2TB Note that Azure installations on A10 VMs require NVIDIA GRID drivers. Azure deployment The Aerial Omniverse Digital Twin (AODT) can be installed on Microsoft Azure using the Azure Installer. The Azure Installer in turn can be downloaded from NGC - Aerial Omniverse DT Installer using version tag 1.0.0. Speciﬁcally, we will ﬁrst download the ﬁles from the Azure folder into a local directory. In that directory, we will create a ﬁle called.secrets and deﬁne the following environment variables: RESOURCEGROUP= WINDOWS_PASSWORD= SSH_KEY_NAME= LOCAL_IP= GUI_OS= NGC_CLI_API_KEY= Variable Description RESOURCEG Microsoft Azure Resource Group ROUP SSH_KEY_NA Name of SSH key stored in Microsoft Azure ME Password length must be between 12 and 72 characters and satisfy 3 of WINDOWS_P the following conditions: 1 lower case character, 1 upper case character, ASSWORD 1 number and 1 special character IP address (as seen by Azure) of the host that will run the provisioning LOCAL_IP scripts GUI_OS Windows NGC_CLI_API NGC API KEY _KEY More information on NGC_CLI_API_KEY can be found here: NGC - User’s Guide. Also, if necessary, the following command can be used to ﬁnd the external IP address of the local machine. Aerial Omniverse Digital Twin 12 curl ifconﬁg.me Once the variables above are conﬁgured, we can use the mcr.microsoft.com/azure-cli docker image to run the provisioning scripts. docker run -it --env-ﬁle.secrets -v.:/aodt -v ~/.ssh/azure.pem:/root/.ssh/id_rsa mcr.microsoft.com/azure-cli The docker container will mounts the downloaded scripts, and it will access to the private SSH key. In the example, the private key can be found in ~/.ssh/azure.pem. Inside the docker container, we can run the following commands: $ az login $ cd aodt $ bash azure_install.sh and the script will create the VMs, conﬁgure the network inbound ports, and download the scripts needed in the next step. At the end, azure_install.sh will show: Use Microsoft Remote Desktop Connection to connect to Username: aerial Password: Logging into the Azure VM We can use Microsoft Remote Desktop Client to connect to the IP address shown at the end of azure_install.sh using the conﬁgured username and password. Once successfully logged, we can then sign into NVIDIA Omniverse and complete the installation of the Omniverse launcher open File Explorer, navigate to C:\AerialODT , right click download_installer and select Run with PowerShell. Aerial Omniverse Digital Twin 13 When the command is ﬁnished, we can open a Command Prompt and type cd c:\AerialODT install_script.bat At the end, the installation script will open a Jupyter notebook in the browser. We can then click on the Library tab in the Omniverse Launcher Window, and Launch the Aerial Omnivere Digital Twin graphical user interface. Dell R750 deployment For a full deployment on prem, we can select the pre-qualiﬁed Dell PowerEdge R750 server. After installing Ubuntu-22.04.3 Server , we can log in using SSH and run the following commands sudo apt-get install -y jq unzip export NGC_CLI_API_KEY= AUTH_URL="https://authn.nvidia.com/token? service=ngc&scope=group/ngc:esee5uzbruax&group/ngc:esee5uzbruax/" TOKEN=$(curl -s -u "\$oauthtoken":"$NGC_CLI_API_KEY" -H "Accept:application/json" "$AUTH_URL" | jq -r '.token') versionTag="1.0.0" downloadedZip="$HOME/aodt_bundle.zip" curl -L "https://api.ngc.nvidia.com/v2/org/esee5uzbruax/resources/aodt- installer/versions/$versionTag/ﬁles/aodt_bundle.zip" -H "Authorization: Bearer$TOKEN" -H "Content-Type: application/json" -o $downloadedZip # Unzip the downloaded ﬁle unzip -o $downloadedZip Again, more information on NGC_CLI_API_KEY can be found here: NGC - User’s Guide. Once the aodt_bundle.zip has been downloaded and extracted, we will continue by running the following command./aodt_bundle/install.sh localhost $NGC_CLI_API_KEY When the installation is complete, we can use a VNC client to connect to the VNC server on port 5901. The VNC password is nvidia. Aerial Omniverse Digital Twin 14 We will then sign into NVIDIA Omniverse and complete the installation in the Omniverse Launcher as for Azure. As before, a Jupyter notebook will also be opened in the browser. We can then click on the Library tab in the Omniverse Launcher Window, and Launch the Aerial Omniverse Digital Twin graphical user interface. Validation Once the Aerial Omniverse Digital Twin graphical interface is running, we can click on the toolbar icon showing the gears and connect to the RAN digital twin. If asked for credentials, we can use the following: username: omniverse password: aerial_123456 Once successfully logged in, we can then select the Content tab (refer to the Graphical User Interface section for further details) and click Add New Connection. In the dialog window, we can then type omniverse-server Aerial Omniverse Digital Twin 15 click OK expand the omniverse-server tree view and double click on omniverse://omniverse-server/Users/aerial/plateau/tokyo.usd This will open the Tokyo.usd map. Once loaded, we will continue by selecting the Viewport tab right clicking on the Stage widget and selecting Aerial > Create Panel twice from the context menu. The ﬁrst panel will be used - by default - for the user equipment UE and the second for the radio unit (RU). Aerial Omniverse Digital Twin 16 With the panels deﬁned, we then can right click in the Viewport select Aerial > Deploy RU from the context menu and click on the ﬁnal location where we would like to place the RU Aerial Omniverse Digital Twin 17 Aerial Omniverse Digital Twin 18 With the RU is deployed, we will then select it from the Stage widget and enable the Show Raypaths checkbox from the Property widget. Aerial Omniverse Digital Twin 19 Similarly, we will right click on the Viewport Aerial Omniverse Digital Twin 20 and select Aerial > Deploy UE from the context menu. Diﬀerently from the procedure for the RU, however, this will drop the UE in the location where the right click took place. Finally, we can select the Scenario entry in the Stage widget set Duration equal to 10.0 Interval to 0.1 click the Generate UEs icon in the toolbar Aerial Omniverse Digital Twin 21 click the Start UE Mobility icon This will start a simulation and update the graphical interface as in the ﬁgure below. By clicking on the Play button in the toolbar, we can then inspect the evolution of the mobility of the UE and the corresponding rays that illustrate how the radiation emitted by the RU reaches the UE. Graphical User Interface The graphical user interface is illustrated in the following ﬁgure and is composed of the following elements. Aerial Omniverse Digital Twin 22 1. Viewport tab The viewport displays the geospatial data that make up the scenario and is used to deploy the radio access network (RAN) nodes or speciﬁc user equipment (UE). E.g., the deployment of a radio unit can be performed by right clicking on a given area of the map and selecting Aerial > Deploy RU from the context menu. To move the RU, once it has been selected, we can instead use Aerial > Move RU. Similarly, to manually deploy a UE, we can use Aerial > Deploy UE. (Procedural deployment of the UEs is illustrated in the simulation section). At the top of the viewport, we can also ﬁnd the settings to change the view type (e.g., top or perspective) or viewport resolution. Finally, the color bar provides the gradient describing the power carried by each individual ray traced by the EM engine, and can be hidden or shown using CTRL+B. 2. Conﬁguration tab The conﬁguration tab is used to set up the simulation and oﬀers the following ﬁelds. Aerial Omniverse Digital Twin 23 db_host: speciﬁes the IP address of the ClickHouse server. db_port: indicates the ClickHouse client port. By default, this ﬁeld is 9000, unless ClickHouse has been installed with non-standard settings. Once db_host and db_port are speciﬁed, the user can connect to the ClickHouse server using the Connect button. If the connection is successful, the indicator next to the button will go from red to green. db_name: this is the name of the database that will be used to store the results generated during the simulation. db_author: this ﬁeld records the author of the database. By default, it is the user ID. Aerial Omniverse Digital Twin 24 db_notes: any additional text that the user intends to add to the database. This ﬁeld can be left empty. nucleus_url: the URL for the Omniverse Nucleus server. nucleus_bc: the name of the Nucleus broadcast channel. This is the channel over which the graphical interface will search for an available worker to perform the RAN simulation. ls_session: the name of the live session. This ﬁeld can be changed in order to import or discard a given RAN deployment on the same scene. ru_url: the URL to the 3D asset used to indicate a radio unit. ue_url: the URL to the 3D asset used to indicate a UE. panel_url: the URL to the asset used to express an antenna planar array. sz_url: the URL to the asset used to indicate zone in which UEs can be procedurally spawned. mat_url: the URL pointing to the asset that describes the ITU P.2040 materials used within the scope of the simulation. 3. Content tab The content tab can be used to browse the content of the Nucleus server, move/copy ﬁles and open the desired scene. 4. Antenna elements tab The antenna tab is used while setting up the simulation to specify the type of antennas that a given antenna panel is composed of the geometrical and polarimetric properties of said panel. The ﬁelds of the tab are illustrated in the following ﬁgure. Aerial Omniverse Digital Twin 25 panel_asset: this ﬁeld speciﬁes which panel is being edited through the tab. antenna_type: when a given antenna site in the panel is selected, it is possible to change the type of antennas installed at the speciﬁc site. This can be done through the list of antennas found at the Antenna combo box. Once a speciﬁc antenna type is selected, it can be applied using the Apply button. If the action is successful, the ﬁeld ant_type under the selected antenna sites is changed to the value indicated in the Antenna combo box. For a given site, there could be at most two colocated antennas of diﬀerent polarization. This can be manipulated through the Dual Polarized check box in the property widget. panel_sh: this ﬁeld represents the uniform horizontal spacing used in the planar antenna array. panel_sv: correspondingly, this other ﬁeld indicates the uniform vertical spacing. panel_cf: this ﬁeld is in the property widget, and indicates the center frequency for which the antenna array has been designed. panel_nh: the number of elements in a row of the planar antenna array. panel_vh: the number of elements in a column of the planar antenna array. Aerial Omniverse Digital Twin 26 panel_erf: this ﬁeld expresses the roll angle, with respect to the vertical axis, of the ﬁrst element in a dual polarized antenna site. panel_ers: the corresponding roll angle for the second element in a dual polarized antenna site. In the tab we also ﬁnd two plots: the gain pattern for the azimuthal cut and the gain pattern for the zenithal cut which, for the antenna type selected from the Antenna combo box, illustrate the contour of the radiation solid along the azimuthal and zenithal planes. Finally, it is worth mentioning that the selection of a given antenna site through the left click of the mouse is additive, i.e., once a site is selected, a second one can also be added, and then a third, and so on. A second click on the selected site, will deselect it. Alternatively, the button Clear Selected can be used in order to remove any selection. 5. Console tab This tab is used to illustrate all warnings and messages collected during the operation of the Aerial Omniverse Digital Twin. Warnings are marked in yellow, and errors are marked in red. Error of consequence for the simulation are also propagated to a dialog box. 6. Stage and property widget The stage widget shows all the assets deployed in the scene and the property widget is the interface for setting their attributes: Environment This entry in the stage widget can be used to set how the scene looks and feels. It allows - for instance - to set the time of the day at the simulated location, with direct consequences on sun illumination. Looks This entry, if present, contains the textures used to describe the buildings. Materials Aerial Omniverse Digital Twin 27 This entry is used to list the material used across the simulation. Each material is characterized by a tuple $\left(a,b,c,d\right)$ of four parameters, so that the relative permittivity of the material is expressed as $ \epsilon_r = a f_{\rm{GHz}}^b - j c f_{\rm{GHz}}^d $ as described in ITU P.2040. Panels This entry collects the antenna arrays used across the simulation. A new type can be added with a right click on the stage widget area and selecting Aerial > Create Panel. Once a panel is selected under this entry, we can set: Antenna Element Type: by pressing the Edit button, we can go to the Antenna Elements tab and select one of the following antenna types: isotropic (point source radiating in all directions with the same intensity and phase). inﬁnitesimal dipole half-wave dipole microstrip patch: reference patch antenna with $\epsilon_r=4.8$ $L = \dfrac{\lambda}{2 \sqrt{\epsilon_r}}$ ($\lambda$ being the wavelength of the carrier) $W = 1.5 L$ user input: this points to the possibility of using Dual Polarized: this ﬂag indicates whether the panel uses antenna arrays with dual-polarized elements. Carrier Frequency: the center frequency at which the antenna in the array will operate. Aerial Omniverse Digital Twin 28 Horizontal Elements ($N_{hor.}$): number of elements in a row of the planar antenna array. Vertical Elements: ($N_{vert.}$): number of elements in a column of the planar antenna array. Horizontal Spacing ($\Delta_{hor.}$): distance between antenna elements along each row of the planar antenna array. Vertical Spacing ($\Delta_{vert.}$): distance between antenna elements along each column of the planar antenna array. Roll of First Pol. Element: angular displacement of the element realizing the ﬁrst polarization (e.g., $45^\circ$) Roll of Second Pol. Element: angular displacement of the element realizing the second polarization (e.g., $-45^\circ$). Has an eﬀect only when the array is composed of dual polarized elements. runtime After they have been generated, this entry collects the trajectories along which the UEs will move during the simulation. RUs This entry in the stage widget collects the deployed RUs, which are added to the scene by right clicking on the viewport area with mouse and selecting Aerial > Deploy RU. By selecting a given RU in the list, we can set two diﬀerent sets of properties: Aerial Properties Cell ID: the unique identiﬁer that deﬁnes the cell supported by the given RU. Panel Type: the speciﬁc antenna array for the RU currently selected. Waveform FFT size: the size of the FFT used in a potential waveform. This parameter is used when Enable Wideband CFRs or Simulate RAN are on in Scenario. Aerial Omniverse Digital Twin 29 Sub-carrier Spacing: parameter indicating the spectral distance between adjacent sub-carriers in the OFDM waveform used by the RU. Mechanical Azimuth ($\phi_b$): azimuth of the RU boresight (indicated as $\hat{b}$ in the ﬁgure below). Mechanical Tilt ($\theta_b$): elevation of the RU boresight (indicated as $\hat{b}$ in the ﬁgure below) with respect to the horizon. Radiated power: the total radiated power, across the whole antenna array, for the given RU. Ray Properties Show Rays: this ﬂag indicates whether the rays shot from a given RU needs to be included in the telemetry visualized after the simulation. Scenario This entry in the stage widget collects all the simulation parameters that can be currently set. This includes: Default UE panel: this is the antenna array associated by default to any UE in the simulation. As we will see later, this parameter can be overridden locally Aerial Omniverse Digital Twin 30 for any given UE. This parameter is oﬀered for convenience to programmatically associate an antenna array type to large populations of UEs. Default RU panel: same concept as described for the default UE panel, but for the RU panel. Enable Temperature Color: this ﬂag indicates whether the rays need to be colored based on their relative power. Max dynamic range: the power range in dB that should be considered for the visualization of the simulations. This range sets the power threshold - from the strongest ray - under which the graphical interface will omit the visualization of rays. # of emitted rays (in thousands): this is the number of emitted rays at a given RU, since the rays are all traced from the RUs. # of scene interactions per ray: the total number of admissible scattering events along any of the traced rays. Max # of Shown Paths per RU-UE pair: this ﬁeld sets the number of visualized rays per RU-UE pair. Ray sparsity: whereas the RAN digital twin calculates the rays for all temporal samples, this ﬁeld allows to only propagate a fraction of such rays to the graphical interface. This is convenient when running long simulations, which would require the transfer of substantial amount of data towards the graphical interface host, which will have to keep the data in RAM. E.g., a Ray sparsity factor of 10 means that the graphical interface will only request the rays once every 10 samples. Batches: the number of UE redrop events during the simulation. This parameter is useful when training neural networks: in lack of aggressive parametrization of the Interval ﬁeld described below, the evolution of the UEs movement is smooth and gradual. Correspondingly, the statistics of the channel does not change appreciable if not across many samples. Thanks to this parameter, it is possible to accelerate the convergence of the training process by means of UE redropping, which occur for every batch. Enabled Wideband CFRs: this ﬂag indicates whether channel frequency responses are also going to be generated. Aerial Omniverse Digital Twin 31 Number of UEs: this indicates how many UEs will be present during the simulation. Currently limited to a maximum of 2000. UE Height: this is the default UE height, which will be applied to all UEs in the scene. UE Max speed: the maximum speed of the UEs in the simulation. UE Min speed: the minimum speed of the UEs during the simulation. The actual speed of given UE will be picked from a uniform distribution going from UE Min speed to UE Max speed. Seeded mobility: indicates whether the random number generators involved in the creation of UE mobility are seeded or not. Seed: in case the previous parameter is set to true, this indicates the seed for the random number generators. Enable training: this ﬂag indicates whether we want to train a neural network while running our simulation. This is currently only supported when the RAN is not being simulated. Simulate RAN: enables the possibility of simulating the behavior of the deployed RUs by adding a physical layer and a medium access control layer to both RUs and UEs. Simulation mode: when Simulate RAN is disabled, this ﬁeld allows to choose between two diﬀerent ways of specifying the simulation timeline. In Slots mode, the simulation timeline is described by the number of slots per batch and the number of realizations of the channel per slot (Samples per slot). Diﬀerently, in Duration mode, the timeline is described by a total temporal length of simulation (Duration) and the sampling period across said duration is set by Interval. If Simulate RAN is enabled, only Slot mode is possible. Slots per batch: number of slots to simulate for every batch in the simulation. The total number of batches in the simulation is speciﬁed in Batches. Samples per slot: number of samples to consider in a given slot. This ﬁeld can either be 1 or 14, indicating whether or not the simulation should account for the Doppler eﬀect. Aerial Omniverse Digital Twin 32 Duration: this number represents the amount of simulated time for which we would like to generate realizations of the radio environment. Interval: this parameter indicates the sampling period with which the radio environment is to be sampled. UEs Once a UE is deployed, using either the viewport context menu (Aerial > Deploy UE) or the programmatic approach described next, the UE will be found under the scope of this entry. By selecting a given UE, we can conﬁgure two diﬀerent sets of properties: Aerial Properties: User ID: the unique identiﬁer that distinguishes a given UE from the others. Panel Type: the speciﬁc antenna array for the UE currently selected. Mechanical Tilt ($\theta_b$): elevation of the UE boresight (indicated as $\hat{b}$ in the ﬁgure below) with respect to the horizon. Radiated power: the total radiated power, across the whole antenna array, for the given UE. Manually created: this ﬂag indicates whether UE has been positioned directly by the user, or it has been generated procedurally by the software. Ray Properties: Show Rays from: this ﬁeld indicate the list of the RUs whose rays will be included in the UE-speciﬁc telemetry visualized after the simulation. Aerial Omniverse Digital Twin 33 World This entry contains the geometry describing the scene. 7. Layer widget The layer widget provides an alternative visualization of how the scene is composed and tracks the changes introduced in the live session from the USD ﬁle as saved on disk. These changes are collected in the authoring layer, which is marked in green. The ﬁgure below illustrates the concept. Aerial Omniverse Digital Twin 34 Any entry with a $\Delta$ superimposed indicates that the assets in the and the attributes in the live session are diﬀerent from what USD ﬁle contains. In general, the layer widget is where we want to reset the scene to its initial state by deleting the introduced deltas using the context menu. 8. Live session widget The function of the live session widget is to synchronize the graphical interface and the RAN digital twin through NVIDIA’s Live Sync technology. Any update added to the scene from the graphical interface side needs to occur while the live session is active. This ensures that any change is propagated to the RAN digital twin. 9. Timeline widget The timeline widget allows the user to manually move across the simulation once the EM solver has calculated the radio frequency (RF) environment. This can be accomplished moving the blue marker across the timeline. The numbers on the timeline correspond to frames. The total number of frames is given by the duration of the simulation divided by the interval separating diﬀerent samples speciﬁed in the Scenario entry of the stage widget. The total is updated every time that the Generate UEs button described above is pressed. 10. Toolbar Aerial Omniverse Digital Twin 35 The standard buttons of the toolbar are documented here. The buttons speciﬁc to the Aerial Omniverse Digital Twin instead are: Attach worker After the scene is ready for simulation, i.e., the RUs and the manual UEs have been deployed the antenna arrays have been created and the Scenario entry in the stage widget has been conﬁgured with the desired parameters, we can use this button to search for an available RAN digital twin worker to carry out the simulation. Generate UEs The ﬁrst step of the simulation process is the generation of the non-manual UEs and of the routes of all UEs. This can be accomplished using this button. The resulting routes can be inspected under the runtime entry in the stage widget, and the play button from the standard toolbar can be used to see how the UEs move along the generated trajectories. Start UE mobility After the trajectories of the UEs have been generated, this button can be used to start the simulation on the RAN digital twin side. Pause UE mobility This button is provided to pause the simulation. Stop UE mobility Similarly this button is provided to stop the simulation. Aerial Omniverse Digital Twin 36 Telemetry refresh After a simulation is complete, the RAN digital twin saves all telemetry in the ClickHouse database speciﬁed in the conﬁguration tab. The graphical interface subsequently read such telemetry and visualized it at the press of the play button in the standard Omniverse toolbar. For RAN simulations, this includes the instantaneous throughput of every UE and its allocated modulation and coding scheme. This telemetry can be observed by selecting one of the UEs under the corresponding entry in the stage widget. However, the rays arriving at a given UE from any selected RU will not show unless the Ray Properties in the property widget of the given RU or UE were set before the simulation began. If not, these rays can be added to the visualized telemetry by setting the Ray Properties after the simulation and refreshing the telemetry. This will ensure that the rays are now visible. Scene importer The Aerial Omniverse Digital Twin builds on NVIDIA Omniverse. As such, it requires to have the geometry of the scenario under investigation in OpenUSD format. Geospatial information, however, is often available and distributed in other formats. To bridge the gap, the Aerial Omniverse Digital Twin comes with a pipeline to import geospatial data in CityGML format. Basic Usage The parameters of the scene importer pipeline are: Parameter Required Description This argument speciﬁes the URL where the USD scene needs to --output Yes be saved. --logging No Set logging verbosity between ```[info If set, the pipeline will perform a conversion between input and output coordinate reference systems, as deﬁned by their EPSG codes. Currently, only the transform from geographic --epsg_in coordinate systems (angular units) to projected coordinate --epsg_out No systems (linear units) is supported. For example, a transform --utm from EPSG:6697 to EPSG:32654 would be expressed as --epsg_in EPSG:6697 --epsg_out EPSG:32654. In lieu of --epsg_out , a UTM zone is also accepted (e.g. --utm 54 ). Aerial Omniverse Digital Twin 37 A scaling factor may be necessary if the target EPSG is in units other than meters. This argument can be used to specify the --scaling No number of centimeters contained in the unit of measurement used in the geospatial data. E.g., 100 for meters (default) and 30.48 for feet. If present, colocated with the input ﬁles and referenced therein, the textures will be copied to the destination speciﬁed by --textures No --output. We can use --textures 0 to ensure that this does not occur. -- textures_o No Explicitly set the texture directory. ut_preﬁx If a digital elevation data (DEM) is available, it may be included in the input ﬁles argument. If a DEM is not available, all buildings --ﬂatten No may be adjusted to a ﬂat ground plane using the --ﬂatten argument. Depending on the data source, there may be a discrepancy -- between a CityGML building bldg:measuredHeight and its adjust_hei rendered height. Where this is a cause for concern and better No ght_thresh geospatial data cannot be obtained, --adjust_height_threshold old can be used to ensure that the building footprints are extruded to bld:measuredHeight. This ﬂag deﬁnes the maximum size that an edge is allowed to have in the mobility domain mesh generated by the pipeline -- (default = 400 in target units of measurements, i.e., mobility_s No centimeters). In large scenes, this may be used to improve cale performance. A warning will be generated in those cases where there are excessive triangles in the resulting mobility mesh. Example - PLATEAU Using the PLATEAU open data as reference, a small model of Tokyo can be built as follows. First, we can run the aodt_gis container using the following command Aerial Omniverse Digital Twin 38 docker run -it --name aodt-gis --entrypoint /bin/bash nvcr.io/esee5uzbruax/aodt- gis:1.0.0 Once inside the container, we can run a script to download the CityGML bundle describing Tokyo using the following commands cd src/aodt_gis/samples/input_data./get_tokyo.sh Next, we will copy template.usd Users//assets to a target folder on the Nucleus server, e.g., Users//plateau and rename the ﬁle to sample.usd. This can be done either with Omniverse launcher or using the Content tab in the Aerial Omniverse Digital Twin user interface. With the source data and target USD URL identiﬁed, we can then run./aodt_gis \../samples/input_data/13100_tokyo23- ku_2022_citygml_1_2_op/udx/bldg/53393599_bldg_6697_2_op.gml../samples/input_data/13100_tokyo23- ku_2022_citygml_1_2_op/udx/bldg/53393690_bldg_6697_2_op.gml../samples/input_data/13100_tokyo23- ku_2022_citygml_1_2_op/udx/bldg/53393589_bldg_6697_2_op.gml../samples/input_data/13100_tokyo23- ku_2022_citygml_1_2_op/udx/bldg/53393680_bldg_6697_2_op.gml --output omniverse:///Users//plateau/sample.usd --epsg_in EPSG:6697 --epsg_out EPSG:32654 which will take the 4 tiles described by each GML ﬁle and merge them into Users//plateau/sample.usd. The parameters --epsg_in EPSG:6697 --epsg_out EPSG:32654 indicate that we are projecting from the source coordinate reference system (EPSG 6697) to the UTM (Universal Transverse Mercator) zone 54N. Aerial Omniverse Digital Twin 39 Unless otherwise conﬁgured, textures will be moved to the destination folder where the generated USD ﬁle resides. RAN Digital Twin The following sections describe how to run simulations in three diﬀerent modes - EM, RAN, and ML training. EM Simulation The EM simulation mode simulates the electromagnetic propagation between transmitters and receivers and does not include the transfer of information from RAN to UEs or vice versa. Attaching a worker from the UI As discussed in the previous sections, the Aerial Omniverse Digital Twin consists of ﬁve subcomponents: the graphical user interface Nucleus ClickHouse the scene importer and the RAN digital twin, where the Nucleus server is the element that allows all the others to interact with one another. Our entry point to running simulations is the graphical user interface. After opening the graphical interface, we can navigate to the Conﬁguration tab to attach to an instance of the RAN digital twin, here referred to also as a worker. Once in the Conﬁguration tab, we shall enter the DB host, DB port for the ClickHouse server and press the Connect button. If the server is reached successfully, the indicator next to the Connect button will go from red to green. Continuing, we can then add a DB name, and optionally a DB author. DB notes can be left empty or can be used to Aerial Omniverse Digital Twin 40 describe key characteristics of the simulation which can help us to retrieve at a later point. We can disconnect from the DB at any time by clicking the Disconnect button. Next, we can enter the Nucleus server URL, e.g. omniverse://<Nucleus IP or hostname> , and the desired live Session Name. The Broadcast Channel Name is an optional parameter to additionally isolate multiple workers running on the same node. By default, Broadcast Channel Name is simply broadcast. Finally, we can specify the URLs of the Assets installed on the selected Nucleus server during installation. After these steps, we are ready to click on the Attach worker button from the toolbar, which is the icon represented by a set of gears. If there is a problem with the installation and the graphical user interface is not able to communicate with the worker, an error window will pop up. Diﬀerently, if the worker attaches successfully, the gear icon will turn green as shown below. To detach the worker, we can click the gear icon again and conﬁrm we want to detach the work. The icon will turn gray again. It is worth mentioning that it is not necessary to explicitly connect to the database each time since attaching the worker will also connect to the database. Of course, the DB host and DB port need to be valid for this to happen. Aerial Omniverse Digital Twin 41 After attaching the worker, we are ready to open a scene. We can do so by going to File > Open and selecting a scene, e.g. tokyo.usd , from the Nucleus server. Alternatively, we can use the Content tab and double click on the ﬁle we want to open. After the UI and the worker both open the scene, we will see a 3D map in the viewport, and the Live session icon in the top right will turn green, indicating that the live session is active. Adding antenna panels Next, we need to create the antenna panels that the RUs and UEs will use. First, we can create a new antenna array by right clicking on the Stage widget and selecting the Aerial > Create Panel entry from the context menu. The new panel can be found in the Stage widget under the Panels entry. By selecting the new panel, we can inspect its properties and change using the Antenna Elements tab and the Property widget as illustrated in the ﬁgure below. Custom antenna patterns In release 1.0, the Aerial Omniverse Digital Twin supports the possibility of importing and using a custom antenna pattern. An example of the format in which the pattern needs to be speciﬁed can be found in /aodt/aodt_sim/antennas/inﬁnitesimal_dipole.csv Aerial Omniverse Digital Twin 42 in the aodt_sim container. To use a custom antenna ﬁle, e.g., user_antenna_pattern.csv , the current process is as follows: 1. Access the host where the aodt_sim container is running or will run 2. cd $HOME/backend_bundle docker-compose down vi docker-compose.yml 3. Edit docker-compose.yml and set services: connector: [...] command:./aodt_sim --nucleus omniverse://omniverse-server --broadcast broadcast --log debug --antenna- pattern-path /aodt_sim/antennas/user_antenna_pattern.csv [...] volumes: -./aodt_sim/antennas:/aodt/aodt_sim/antennas [...] 4. Bring the container up again docker-compose up -d Deploying RUs To deploy new radio units (RUs), it is suﬃcient to right click on the map with the mouse and select Aerial > Deploy RU. This will create a movable asset which follows the mouse. Once the location of the RU is found, we can click to conﬁrm the position of the RU. The RU can be later moved by selecting it, right clicking on it and using Aerial > Move RU from the context menu. After a given RU is in the intended position, its attributes can be modiﬁed using the property widget. Most importantly we need to associate a Panel Type is the ﬁeld is empty. Deploying UEs The UEs can be deployed in two ways - procedurally or manually. To deploy manually, we can navigate to the viewport and right click on the position where we would like the UE to be located. Selecting Aerial > Deploy UE from the context menu will create a capsule in Aerial Omniverse Digital Twin 43 the desired location. The corresponding entry in the UEs group of the stage widget will have the Manually Created ﬂag active. For a manually created UE, we can also specify its mobility path by clicking on the Edit Waypoints button in the UE property widget. Then, in the viewport we can draw a polyline deﬁning the intended trajectory of the UE across the map. This approach is typically suﬃcient to simulate small scenarios, where the number of UEs is limited. For larger populations of UEs, we can procedurally generate a set of UEs by changing the parameter Number of UEs in the Scenario entry of the Stage widget. Pressing the Generate UEs button in the toolbar, when the worker is attached, will procedurally create enough UEs, so that the total number of UEs the one speciﬁed in Scenario. We can constrain where the procedural UEs are generated and can move by creating a Spawn Zone, i.e., by right clicking in the viewport and selecting Aerial > Deploy Spawn Zone. This will create the bounding box show in the ﬁgure. Aerial Omniverse Digital Twin 44 We can adjust the size and position of the bounding box using the Move, Rotate, and Scale buttons in the toolbar. More in detail, after selecting one of such actions, we can drag the red/blue/green arrows and rectangles show in the ﬁgure to execute the desired transformation. Aerial Omniverse Digital Twin 45 It is important that bounding box intersects with the ground of the stage. Otherwise, the procedural UEs will not be dropped in the spawn zone. For this reason, we might want to modify the spawn zone bounding box from the top view, instead of perspective view (the view can be changed from the Camera view widget at the top of the viewport). If there is no spawn zone or if the spawn zone bounding box is too small, then procedural UEs will be dropped in a random position in the stage. Procedural and manual UEs can be mixed for a given deployment, and manual UEs are not moved at every press of the Generate UEs button. Changing the scattering properties of the environment The proper association of materials to the scene geometry plays a key role in producing a realistic representation of the radio environment. Currently, materials can be assigned to each building and to the terrain as a whole. To do so, we can select the building we want to edit using either the stage view or the viewport and then proceed to alter the ﬁeld Building Material from the property widget; similarly, for the terrain, we can select the ground_plane asset in the stage view and then modify the Ground Plane Material ﬁeld from the property widget. For the buildings, it is also possible to batch assign a given material to the whole map by selecting World/buildings in the stage widget. Aerial Omniverse Digital Twin 46 With a similar procedure and interface, we can also assign two other important properties: Enable RF: this ﬂag indicates whether the mesh or meshes representing one building, all of the buildings or the terrain can interact with the electromagnetic ﬁeld. If this ﬂag is not enabled the electromagnetic ﬁeld will not be able to interact with the geometry of the selected asset; Enable Diﬀusion: this option in turn speciﬁes whether the mesh or meshes - again representing one building all of the buildings or the terrain can interact with the electromagnetic ﬁeld in a diﬀuse fashion, i.e., whether the surface of such meshes can produce non-specular reﬂections. Running simulations Before running the simulation, it is important to check that all of the parameters in the Scenario property widget are aligned with our intentions that Enable Training and Simulate RAN are unchecked. As mentioned in the previous section, the duration and the sampling period of the simulation is determined by the Simulation Mode in Scenario. The user is given two options: duration and interval, or slot and symbol per slot. Simulation Mode: Duration requires to set Batches, Duration, Aerial Omniverse Digital Twin 47 Interval Simulation Mode: Slots instead requires Batches, Slots Per Batch, Samples Per Slot. Refer to the Graphical User Interface section describing the Scenario stage widget for more details on these and other parameters. Now, we can generate the UEs and the trajectories that they will follow during the simulation using the Generate UEs button. The trajectories appear in the viewport widget as polylines in white on the ground plane, and in the Stage widget as entries of the runtime scope. Once the UE and their trajectories are available, we can start the simulation by pressing the Start UE mobility button in the toolbar. While running, the simulation can be paused and stopped using the Pause UE mobility and the Stop UE mobility buttons of the toolbar. While the simulation is paused, the Generate UEs button can be pressed but it will not generate a new set of trajectories. In order to so, the simulation will have to be stopped ﬁrst using the Stop UE mobility button. The progress of the simulation is shown in the progress bar. Viewing simulation results When the simulation is complete, press the Play button on the toolbar or move the blue indicator in the Timeline widget to a speciﬁc frame of interest. To stop the replay, we can click the Stop button. The visualization of the rays can be turned on or oﬀ for each RU-UE pair by selecting the UE ahead of the simulation and using the Property widget as illustrated in the ﬁgure. Aerial Omniverse Digital Twin 48 If a given RU is not selected before the simulation was launched, and we are interested in seeing the rays from that RU, we can use the Refresh telemetry button. Radio environment The radio environment results stored in the database are for the RU to UE direction, i.e., for downlink. Speciﬁcally, if we take the total transmitted power $P^{\left(RU\right)}$ at RU, the number of polarizations used at RU per transmitting antenna site \ (N^{\left(RU\right)}_{pol.}\) the number of horizontal sites used at the RU $N^{\left(RU\right)}_{hor.}$ the number of horizontal sites used at the RU $N^{\left(RU\right)}_{vert.}$ the number of FFT points $n$ the channel frequency response per link $\mathbf{H}_{i,j}^{\left(UE\right)}\left( k \right)$ observed at the UE for a given subcarrier $k$, across the link from the $i$- transmitter antenna to the $j$-th receiver antenna the channel frequency response per link $\mathbf{H}_{i,j}^{\left(ch\right)}\left( k \right)$ observed at the UE for a given subcarrier $k$, across the link from the $i$- transmitter antenna to the $j$-th receiver antenna when each subcarrier is allocated unitary power at transmission the results are such that $ \left = \dfrac{P^{\left(RU\right)}}{n \cdot N^{\left(RU\right)}_{pol.} \cdot N^{\left(RU\right)}_{hor.} \cdot N^{\left(RU\right)}_{vert.}} \left. $ The set of $\left\ {\mathbf{H}_{i,j}^{\left(UE\right)}\left( k \right)\right\}_{i,j,k}$ is stored in the cfrs table discussed in the next section. If we deﬁne $ \mathbf{h}_{i,j}^{\left(UE\right)} = \dfrac{{\rm{iFFT}}_n \left[ \mathbf{H}_{i,j} ^ {\left( UE \right)}\right]}{\sqrt{n}} $ and the geometrically calculated channel impulse response as $ h^{UE}_{i,j} \left(t\right) = \sum_w h^{\left(w \right)}_{i,j} \delta\left(t - \tau^{\left(w \right)}_{i,j} \right) $ we also have $ \left = \left $ where the Aerial Omniverse Digital Twin 49 set of $\left\{h_{i,j}^{\left(UE\right)}\right\}_{i,j}$ is stored in the raypaths table discussed in the upcoming section. Finally, if we are interested in calculating the channel frequency response in uplink, we can do so by imposing $ \left_{UL} = \dfrac{P^{\left(UE\right)}} {N^{\left(UE\right)}_{pol.} \cdot N^{\left(UE\right)}_{hor.} \cdot N^{\left(UE\right)}_{vert.}} \cdot \dfrac{N^{\left(RU\right)}_{pol.} \cdot N^{\left(RU\right)}_{hor.} \cdot N^{\left(RU\right)}_{vert.}}{P^{\left(RU\right)}} \left_{DL}. $ RAN simulation The RAN simulation mode builds on top of the EM mode and adds key elements of the physical (PHY) and medium access control (MAC) layers. To enable the simulation of the RAN, we can select the Scenario entry under the Stage widget and enable the Simulate RAN checkbox, as shown in the ﬁgure below. This will restrict the Simulation mode ﬁeld in Scenario to Slots. We can then deﬁne the number of batches, number of slots per batch and samples per slot as in EM mode. Speciﬁcally, when Samples Per Slot is set to 1, a single front-loaded realization of the channel will be used across the whole slot whereas when Samples Per Slot is set to 14, every OFDM symbol will be convolved with a diﬀerent channel realization. RAN Parameters The RAN parameters are stored in /aodt/aodt_sim/src_be/components/common/conﬁg_ran.json Aerial Omniverse Digital Twin 50 where the following parameters can be changed Meaning Default value gNB noise ﬁgure Noise ﬁgure of RU power ampliﬁer 0.5 dB UE noise ﬁgure Noise ﬁgure of UE power ampliﬁer 0.5 dB DL HARQ enabled Enables DL HARQ 0 UL HARQ enabled Enables UL HARQ 0 1: DDDDUUDDDD Supported TDD patterns, additional TDD patterns 2: DDDDDDDDDD patterns can be added 3: UUUUUUUUUU 2 (i.e., Simulation pattern Speciﬁes the TDD pattern for simulation DDDDDDDDDD) Max scheduled UEs Maximum number of UEs per TTI per cell for 6 (max: 6) per TTI - dl DL Max scheduled UEs Maximum number of UEs per TTI per cell for 6 (max: 6) per TTI - ul UL Simulation After the parameters described in conﬁg_ran.json are set, we can run the simulation using the same sequence of as for the EM mode. The results are then propagated to the graphical interface, where we can visualize instantaneous throughput and modulation coding scheme (MCS) for each UE the local console, where detailed scheduling information (e.g., PRB allocations and number of layers) are printed slot-by-slot the selected ClickHouse database, where the full telemetry will be stored. Graphical user interface After the simulation is complete, we can select a speciﬁc UE under in the Stage widget and press the play button from the toolbar. In the Property widget, we will see the time series of the instantaneous throughput and the MCS allocated to the UE, for both downlink and uplink, as in the ﬁgure below. Aerial Omniverse Digital Twin 51 Additionally, we can observe the instantaneous throughput of the UE directly above their representation in the viewport, as shown below. Aerial Omniverse Digital Twin 52 The MCS allocated by the MAC scheduler in serving a given UE can also be found right below the instantaneous throughput. Aerial Omniverse Digital Twin 53 Local console If accessible, additional details can be observed in the console where the RAN digital twin is running. At the end of each slot, a table is printed listing all scheduled UEs, PRB allocations (start PRB index and number of allocated PRBs), MCS, number of layers, redundancy version in presence of HARQ, pre-equalization SINR, post-equalization SINR, and CRC results, with 0 denoting a successful decoding. Aerial Omniverse Digital Twin 54 ============================================== results ================================================ cell idx grp idx rnti startPrb nPrb MCS layer RV sinrPreEq sinrPostEq CRC 0 0 94 176 80 4 2 0 5.67 4.16 0 0 1 95 4 36 0 2 0 -3.94 -2.43 0 0 2 155 40 40 3 2 0 1.47 1.10 0 0 3 175 80 96 27 1 0 34.94 40.00 0 0 4 192 256 16 1 1 0 -6.14 -1.21 0 0 5 193 0 4 26 2 0 36.21 26.23 9860658 1 6 28 200 16 15 1 0 10.12 16.60 0 1 7 58 216 56 10 1 0 3.95 10.01 0 1 8 89 0 80 24 1 0 12.64 22.68 7891203 1 9 92 80 12 27 1 0 35.69 40.00 0 1 10 178 148 52 12 1 0 6.74 11.62 0 1 11 184 92 56 7 1 0 2.02 7.28 0 2 12 34 244 28 27 1 0 34.56 39.19 0 2 13 47 124 48 15 1 0 6.36 15.37 0 2 14 60 16 92 16 1 0 5.22 15.24 0 2 15 68 172 72 9 1 0 3.41 9.45 0 2 16 194 0 16 11 1 0 3.72 10.74 0 2 17 199 108 16 3 2 0 9.68 4.18 0 3 18 23 200 8 27 1 0 31.78 37.85 0 3 19 56 208 28 20 1 0 14.68 19.20 0 3 20 57 0 60 3 1 0 -0.52 5.20 0 3 21 62 60 140 27 1 0 33.20 37.99 0 3 22 160 260 12 15 1 0 14.91 20.29 0 3 23 187 236 24 27 1 0 36.80 39.92 0 ====================================================================== ClickHouse database Comprehensive telemetry data is available in the telemetry table of the database used for the simulation. For instance, clickhouse-client aerial :) select * from aerial_2024_4_16_14_28_33.telemetry SELECT * FROM aerial_2024_4_16_14_28_33.telemetry Query id: e463ec6a-4e11-4197-88e0- 8762a630181d batch_id slot_id link ru_id ue_id startPrb nPrb mcs layers 0 0 UL 0 46 28 132 0 1 372 0 1 30000 0 0 UL 0 49 0 28 0 1 80 0 1 30000 0 0 UL 0 53 160 24 0 2 141 0 1 30000 0 0 UL 0 94 184 88 0 2 497 0 0 30000 0 0 UL 1 124 0 272 0 1 769 0 1 30000 0 1 UL 1 124 0 272 9 1 7813 0 1 30000 0 1 UL 2 34 0 272 0 1 769 0 1 30000 0 1 UL 3 23 20 252 0 1 705 0 1 30000... where the meaning of each column is explained in the Database schemas. MAC Scheduling Aerial Omniverse Digital Twin 55 The MAC scheduling tasks are performed by cuMAC, with full support for both UL and DL, HARQ and single-cell as well multi-cell jointly scheduling. The data ﬂow for the scheduling process is illustrated in the following ﬁgure. In each time slot, after the required input data gets passed to cuMAC, the following scheduler functions are executed serially on GPU: UE selection: UE down-selection using the SINR reported reported by the PHY layer, PRB allocation: PRB allocation for the selected UEs using the CFRs from the EM engine Layer selection: layer selection for each selected UE MCS selection: MCS selection for each of the selected UEs using the SINR reported from the PHY. An outer-loop link adaptation is employed to add a positive/negative oﬀset to the reported SINR. The oﬀset is tuned by the ACK/NACK result of the last scheduled transmission for the given UE. ML training The Aerial Omniverse Digital Twin can be used to generate site-speciﬁc data to train machine learning models. After running a simulation, we can import simulation data from the ClickHouse database to train a model oﬄine. More details of the data saved for a simulation is available in the appendix of this guide. In order to speed up development workﬂows, the Aerial Omniverse Digital Twin can also be used to train models online, while the simulation is evolving. This is achieved by Aerial Omniverse Digital Twin 56 exposing Python bindings from the aodt_sim application. For each simulation time step, aodt_sim passes state, including UE position, speed, and channel data from the EM engine to Python code outside of the application. This allows the user to train a model using a machine learning framework of choice. NOTE To avoid slowing down simulations, it is recommended not to use raw loops and other complicated logic in pure Python, and instead rely on optimized GPU/CPU kernels, e.g. in PyTorch or NumPy. Example - training a channel predictor To illustrate how to perform online training, we can use a minimal example to train a channel predictor based on the channel frequency responses (CFRs) computed by the EM engine. In subsequent releases, we will provide more examples to support training additional PHY/MAC components. Channel aging is a well-known problem for reciprocal beamforming, especially for UEs moving with high speed. This is due to the diﬀerence between in the radio environment between when the channel is sounded and when the base station applies the beamforming weights. One way to address this problem is to use a neural network to predict the channel when the beamforming weights are planned to be applied. To train a neural network attempting to predict the channel, we can start by setting the following parameters in the Scenario stage widget. Scenario: 5 UEs and 1 RU Antenna Panels: 2 horizontal, 2 vertical elements, with dual polarization unchecked Batches: 250 Slots per batch: 6 Sample per slot: 1 UE speed: min and max speeds set to 2.0 m/s Enable Training: checked Simulate RAN: unchecked Aerial Omniverse Digital Twin 57 In this example, the channel predictor treats the channel from each RU and UE antenna pair independently, so we can optionally add more RUs, UEs, and antenna elements, resulting in more channels generated per batch. Our neural network will estimate the channel 5 slots in advance. That is, given the channel at slot 0, it will predict the channel at slot 5. Thus, we set the slots per batch to 6. We set the number of batches to 250, which provides a good tradeoﬀ between simulation time and achieving a reasonable training loss for this example. At each batch, the UEs are redropped. Following the steps described in the EM mode, we can click Generate UEs and Start UE mobility to start the simulation. After the simulation ﬁnishes, the training and the validation losses are retrieved from the training_result table of the database and shown as part of the properties of Scenario. In the example, such losses are compared to the loss from a LMMSE ﬁlter attempting to perform the same action. Such loss appears in the graphical interface as baseline loss. In the next section, we will go into further detail on how to train a more generic model. Example - training our own model In this section, we will discuss the Python API to train our own model using the Aerial Omniverse Digital Twin. As previously mentioned, the API exposes position information from the UE mobility model and channel information from the EM engine. Thus, it is possible to train any other model that relies on such data. The following discusses the minimum set of functions and data structures to consider when training any of such models. Speciﬁcally, the aodt_sim application makes calls into the Python source code in the channel_predictor directory via Python bindings. The directory includes the following ﬁles. |-- aodt_sim |-- channel_predictor | |-- channel_predictor.py | |-- channel_predictor_bindings.cpython-310-x86_64-linux-gnu.so | |-- conﬁg.ini | |-- data_source.py | |-- plot_channels.py | |-- torch_utils.py | |-- train.py | |-- trainer.py | `-- weiner_ﬁlter.py 1 directory, 10 ﬁles Only the Trainer class with member functions scenario and append_cfr in channel_predictor/trainer.py are required for the aodt_sim Python bindings, and must Aerial Omniverse Digital Twin 58 therefore be present in any user-modiﬁed Python code. The scenario function is called once at the beginning of a simulation, and the append_cfr function is called for every time step of the simulation. The rest of the ﬁles are local to the channel predictor example and do not interface with the aodt_sim application. The reader can refer to the Python docstrings in those ﬁles for further details. The user may substitute them with their own Python code. class Trainer(): """Class that manages training state""" def scenario(self, scenario_info, ru_ue_info): """Load scenario and initialize torch parameters Args: scenario_info (ScenarioInfo): Object containing information about the simulation scenario ru_ue_info (RuUeInfo): Object containing information about RUs and UEs Returns: int: Return code if status was successful (=0) or not (

Aerial Omniverse Digital Twin PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue