BostonTwin: the Boston Digital Twin for Ray-Tracing in 6G Networks

Digital twins are now a staple of wireless networks design and evolution. Creating an accurate digital copy of a real system offers numerous opportunities to study and analyze its performance and issues. It also allows designing and testing new solutions in a risk-free environment, and applying them back to the real system after validation. A candidate technology that will heavily rely on digital twins for design and deployment is 6G, which promises robust and ubiquitous networks for eXtended Reality (XR) and immersive communications solutions. In this paper, we present BostonTwin, a dataset that merges a high-fidelity 3D model of the city of Boston, MA, with the existing geospatial data on cellular base stations deployments, in a ray-tracing-ready format. Thus, BostonTwin enables not only the instantaneous rendering and programmatic access to the building models, but it also allows for an accurate representation of the electromagnetic propagation environment in the real-world city of Boston. The level of detail and accuracy of this characterization is crucial to designing 6G networks that can support the strict requirements of sensitive and high-bandwidth applications, such as XR and immersive communication.


INTRODUCTION
The ever-increasing complexity of networks and digital systems calls for new comprehensive methodologies for their design and optimization.In this context, the concept of Digital Twins (DTs) has emerged as a powerful tool and abstraction in a variety of applications, including networking and multimedia solutions [5,18,24,26].Twinning recreates real-world scenarios in a digital format with an extremely high level of realism.In this way, the DT can be used as a safe playground where to test and evaluate different configurations for the real-world system (i) without impacting its performance and the quality of service to the end-users; and (ii) possibly anticipating and evaluating multiple versions of the realworld system in a faster-than-real-time environment.In addition, a high-fidelity digital replica allows for the collection of data that can be used to train Artificial Intelligence (AI) models, with flexibility and potential for automation which are difficult to achieve in the real world.
DTs have been leveraged in prior studies on networking [14,19,28,32,40,42,43], to improve optimization and configuration of wireless networks, planning monitoring solutions, and improve vehicular network and satellite systems performance, and in multimedia systems [4,22,35,41], to profile quality of service for mobile users streaming videos, manage resources for multicast streaming, and optimize quality of experience in XR systems.Implementing digital twins, however, is a challenging task, especially in wireless systems where the digital world needs to accurately replicate realworld propagation, protocol stacks, applications, and user patterns.We took a first step toward defining a high-fidelity DT for wireless networks in [39], introducing the Colosseum wireless network emulator as a DT of over-the-air wireless networks and toolchains for the twinning of wireless channels and networks.
In this paper, we take a further step in the creation of DTs that can realistically replicate wireless scenarios.We introduce Boston-Twin, the first fully automated toolchain, and dataset for city-scale twinning, focusing on the city of Boston through open data released by the Boston Planning and Development Administration (BPDA).
We implement and open source a set of Application Programming Interfaces (APIs) for the integration of this 3D model in popular ray tracers, e.g., NVIDIA Sionna [20,21], and the fusion of the city mesh with additional objects in their real-world locations, e.g., base stations, for cellular networks design.The BostonTwin 3D model allows for capturing fine-grained details-at a city scale-that can fundamentally alter the propagation of wireless signals, and thus the accuracy of a DT.The code and data are publicly available at [37] and [36].
Our contributions toward creating BostonTwin are as follows: • We convert the BPDAs 3D building model [9] to a metricbased model in the PLY format widely used by ray tracers, e.g., Mitsuba, which allows the programmatic and fast rendering of 3D scenes for graphical or Radio Frequency (RF) ray tracing [25].We provide the code to perform such conversion and also the processed dataset at [37].nodes and points of interest, the dynamic tuning of the level of details and accuracy of the DT based on the user requirements, and the extraction of sub-scenes from the complete city scenario.• Leveraging the BostonTwin API, we extend the city-scale 3D model with information on the location of points of interest for RF ray tracing.Notably, we consider the locations of wireless cellular base stations in the city of Boston, also released as open data [8].This methodology can be adapted to integrate additional elements, e.g., mobile receivers, other wireless systems, or sources of interference.• The dataset in the PLY format and the BostonTwin APIs directly feed information on the 3D mesh to the NVIDIA Sionna electromagnetic ray tracer, which we use to profile propagation in different tiles of the city of Boston and support for 6th generation (6G) wireless multimedia use cases (e.g., XR).
The BostonTwin approach and APIs introduce a simplified approach to interact with DT models, together with an accurate cityscale 3D dataset.Compared to existing DTs [6,16,33], BostonTwin supports an unprecedented scale, is open-source, and is integrated with other open-source, state-of-the-art tools, thus supporting open science and research.
The rest of the paper is organized as follows.Section 2 introduces the data used in BostonTwin, as well as the Python classes that can be used to manipulate the 3D models and geolocated points of interest.Section 3 describes the workflow we propose to use and interact with BostonTwin and RF ray tracers.Section 4 discusses a use cases of BostonTwin, i.e., the large-scale evaluation of coverage and data rates for immersive communications in a urban environment.Finally, Section 5 concludes the paper and discusses future extensions.

THE BOSTONTWIN FRAMEWORK
The BostonTwin framework consists of the API and of two main data sources, namely, the 3D building model and the base station geographic information.The corresponding data is accessible through the BostonModel and BostonAntennas Python classes, that provide several utility functions to manage, manipulate, and interact with the dataset.The dataset itself is organized as reported in Fig. 2.
In the following subsections, we report a brief overview of the two classes that support the BostonTwin operations, whereas the API and the workflow to interact with the digital twin are described in Section 3.

The BostonModel Class
The BostonModel class contains the information and the methods to access the 3D model of the buildings of the city of Boston.The data was obtained through the publicly available Boston Planning and Development Administration (BPDA) Citywide 3D Smart Model [9], which in turn originated from the 2011 planimetry of Boston, and has been regularly updated since then using data from BPDA Urban Design models, CyberCity 3D, and LiDAR sources.Currently, the data is organized and managed according to the citySchema model [12] by the BPDA Geographic Information System (GIS) Lab.Thanks to the open-source management format, which fulfills the requirements of the ISO Reference Model for Open Archival Systems [30], the data is easily maintained, updated, and expanded.Furthermore, as more cities adopt the citySchema standard and the 3D models get further refined, the API and the corresponding digital twining framework provided through this work can be enhanced and expanded to compatible cities and scenarios.The 3D data covers the entire city of Boston and is organized in  square tiles of 1524 by 1524 m (5000 by 5000 ft).The tile are named according to the format BOS_<L>_<N>, with L∈ {A, B, . . ., O} and N∈ {1, 2, . . ., 13}.The complete list of currently available tiles is  2. A map representing the LOD of the models in Downtown Boston is shown in Fig. 3.
While the citySchema offers numerous advantages, the data format is not suitable for physics simulations or programmatic access.First, all the data has to be converted to International Organization for Standardization (ISO) units, i.e., in meters.Second, the custom CRS makes it difficult to include data from other sources, e.g., the geolocated data.This limits the possibility of creating a digital twin with additional elements in the scenario, which is imperative for some use cases, e.g., in wireless communication network design.Finally, although the BPDA website and dataset offer numerous resources for visualization, catalog queries, and importing the models in commercial applications, the resources to access the data through programming languages such as Python are limited.Therefore, we decided to keep the same tile-based organization, while converting the models to a different CRS and format, and providing a georeferencing API, described in Section 3.
Specifically, the unit of the OBJ models was converted to meters and the meshes were centered in [0, 0], so that the vertex coordinates are all referred to the center of the model itself.On one hand, this streamlines the visualization and the processing of the single meshes.On the other, it moves the burden of defining the CRS to the user, who can thus define a custom one more easily.To reverse the translation and geolocate the meshes, we include the geographic reference for each model in the model catalog of each tile (BOS_<L>_<N>.geojson),along with the information for the tile itself (BOS_<L>_<N>_tileinfo.geojson).Furthermore, we convert the OBJ models to PLY binary files, which is another popular, standardized data format that is supported (and encouraged [25]) by most of the open-source 3D processing and rendering libraries and tools, e.g., Blender [11], open3D [44], and Mitsuba [25].The resulting directory and file tree are reported in Fig. 2, and publicly available at [36].

The BostonAntennas Class
The Boston GIS department released also the geolocated data for the requests to install small cell antennas/Distributed Antenna System (DAS) that were approved by the City of Boston.The data was released in two datasets, "DAS/Small Cell Approved Locations" [7] and "Wireless Antenna Installation Requests Approved" [8] for the requests approved before and after the 01/01/2017, respectively.The CRS of both datasets is WGS84.We merged them into a single dataset, uniforming the column names and information (antennas.geojson in Fig. 2).
Differently from the BostonModel class, the antenna data is 2D and contains no information on the elevation of the antennas.However, in most cases, the type of mount where the antenna was installed (New_Pole_Type) identifies a possible set of heights [34].

The BostonTwin Class
The digital twin is implemented through the BostonTwin class.The class contains a (BostonModel, BostonAntennas) pair to access the information on the city-scale model.An instance of the BostonTwin represents a specific scene, and several utility functions to access it.
A scene is defined by its geographic boundaries (<scene_name>_ tileinfo.geojson in Fig. 2) and includes all the digital twin elements within the corresponding area, i.e., the 3D model of the environment and the location of the base stations in the area.Specifically, a scene can be accessed through the corresponding model catalog, or through the Mitsuba scene files (<scene_name>.geojson and <scene_name>.xml in Fig. 2).The Mitsuba files contain some basic settings for the 3D rendering of the scene, the reference to all the models in a scene, and the information to position the meshes within the scene local CRS.The origin of the local coordinate system, in meters, is at the center of the scene.The Mitsuba scene, when composed of PLY meshes, can be directly imported into Sionna, where an interactive API for visualization and rendering is available, as explained in Section 3. As mentioned in Section 2.1, we keep the tiling organization and defined a scene for each tile, keeping the corresponding names (BOS_<L>_<N>).However, the user can define custom scenes either by adding the corresponding files to the data directory or by using the dedicated API, as explained in Fig. 4.
Finally, the material of the surfaces that interact with the Electromagnetic (EM) signal has a significant impact on its propagation.In Sionna, a set of International Telecommunication Union (ITU) materials with the corresponding EM properties [23] is available for the 3D meshes.Each mesh is associated with a material.In the predefined scenes of BostonTwin, the materials are assigned based on the type of model reported in the Model Catalog (ITU brick for "Wall", ITU concrete for "Building", ITU medium-dry ground for the ground).The user can easily define new materials or change and customize the current ones through the Sionna API or in the Mitsuba scene files, leveraging the georeferencing and descriptive information provided in the Model Catalog.As the LOD of the BPDA data increases in future releases, we plan to support meshes with components of different materials.

THE BOSTONTWIN PIPELINE
In this section, we describe the workflow reported in Fig. 4 and the API that we provide to interact with the BostonTwin framework.
Scene Loading.The user can load one of the predefined scenes (tiles) by specifying the tile name according to the convention presented in Section 2.1 (top red arrow in Fig. 4).When doing so, the scene is loaded into Sionna, and the base station database is filtered to extract only the base stations in the tile.Alternatively, the user can specify a geographical location (left red arrow in Fig. 4), either through a (Longitude, Latitude) tuple (default CRS: WGS84/EPSG:4326), or through a GeoPandas GeoDataFrame [15] with a different CRS, and a radius.Then, the elements within the radius from the specified point are added to a new scene.
Thanks to the georeferencing capabilities of the API, BostonTwin can be easily integrated with data from any kind of sources, e.g., from Simulation of Urban MObility (SUMO) [31], a traffic simulator that can provide realistic traffic patterns to be injected into the  digital twin.Furthermore, the compatibility with the citySchema format makes it easy to integrate the 3D data from other datasets.
Radio Devices Deployment.As reported in Section 2.2, the digital twin contains the information on the location of the approved base stations within the City of Boston, that allows the deployment of the radio devices at realistic locations.Once the scene has been loaded, a list of base stations within the corresponding area is available.The user can then select which ones to deploy in Sionna, giving each a role (either as a Sionna Transmitter or Receiver).Furthermore, the user can add devices at custom locations, that can be specified as geographic or local coordinates, and significantly facilitates the deployment of, e.g., users.
RF Characterization through Ray Tracing.As reported in Fig. 4, BostonTwin relies on the Sionna ray tracer to simulate the EM wave propagation within the digital twin.The ray tracer is based on Mitsuba 3 and can parallelize the computation on the GPU, thus achieving unprecedented results in terms of speed and scalability (for further details, we refer the readers to [20]).Thanks to these characteristics, and to the possibility of rendering the digital twin through Mitsuba and interacting with it through the Sionna API, we identified it as the most promising open-source candidate for our work.As showcased in Section 4, the Ray Tracer (RT) allows to obtain detailed coverage maps for large scenarios with a runtime in the order of seconds, even with hundreds of thousands of triangles (Table 1).Furthermore, the point-to-point channel between each pair of devices can be computed with an arbitrary number of reflections, and with or without diffracted and scattered rays.3D Model Simplification.Finally, BostonTwin offers some utility functions that can further enhance the usability and the interaction with the digital twin.Large-scale EM simulations can require a huge amount of memory, which depends also on the number of triangles [29].Thus, the 3D meshes of the building models of BostonTwin can be simplified, reducing the number of triangles to cut both the hardware requirements and the simulation runtime.To do so, we leverage the Open3D library, that offers several methods to simplify the meshes.The simplified version of the 3D data can then be imported, loaded, and used through the same pipeline as the original one.However, the reduction in the number of vertices should be used carefully, as decreasing the precision can lead to  [2] inconsistent geometries, besides degrading the accuracy of the EM characterization.
We provide a detailed documentation and guide on the Boston-Twin APIs in the open-source code repository [37].

DIGITAL TWIN FOR IMMERSIVE COMMUNICATIONS
We showcase the potential of BostonTwin as a digital twin considering a simplified 6G scenario for immersive communications.Specifically, we consider 12.7 GHz as carrier frequency, one of the candidate frequencies in the novel FR-3 bands of interest for 6G systems [13,27].Particularly during the initial evaluation phase, when new frequency allocations are discussed, having reliable simulation tools is of the foremost importance, e.g., to assess the impact on existing stakeholders [38], and to characterize the propagation and the corresponding deployment design in different environments.
To do so, an accurate propagation model is necessary, but also a detailed representation of the propagation environment.Thus, as FR-3 offers more bandwidth than the traditional FR-1 with better propagation characteristics than millimeter waves, we  3.We start by characterizing the SNR in each tile by modeling the propagation of EM waves using the Sionna ray tracer considering all the base stations in each tile and computing it over a 400 MHz bandwidth .From Fig. 5a we can observe that thanks to the high density of the base stations, the downtown area (G_4-5, H_3-4, I_3-4) is well serviced, with a peak SNR of more than 24 dB.On the contrary, the southernmost areas have a lower base station density and thus a lower coverage.The SNR where the signal can propagate in free space, i.e., without the building obstruction, is visible in the open areas such as the Charles River banks (e.g., F_4, G_4) or the Boston Common Park (central area in tile H_4).
Then, we compute the achievable capacity  using the Shannon capacity equation  =  log 2 (1+SNR).We consider the throughput requirement for two immersive communications use cases, i.e., 30 Mbps for XR [3,10,17] and 700 Mbps for a use case defined in the 3GPP technical specification [2], i.e., "video sharing between UEs supporting V2X application", and filter out the locations where the capacity does not meet the requirements.Fig. 5b shows that the current base station can deliver enough throughput to support the datarate of the XR application in large areas of the city.On the contrary, the capacity by the V2X use case is met only in the immediate surroundings of the base stations, even when using the frequencies in FR-3, calling for a denser deployment, higher transmit power or even larger bandwidth.
Using BostonTwin, it is thus possible to analyze the existing scenarios, plan and test further network deployment, study its dimensioning, and use it as a safe, yet realistic playground for innovative orchestration solutions on an unprecedented scale.

CONCLUSIONS
In this paper, we introduced a city-scale twinning framework that simplifies ray-tracing studies for next-generation wireless networks and multimedia applications.Starting from open data from the city of Boston, we have created a dataset that can be easily parsed, manipulated, and imported in popular RF ray tracing frameworks.In the paper, we first described the dataset and code that was developed to interact with it.Then, we introduced a workflow that takes the 3D models, combines them with custom geolocated points of interest, and feeds this information to the NVIDIA Sionna ray tracer.In the last part of the paper, we focused on a use case that showcases the flexibility and scale of BostonTwin, using RF ray tracing in the accurate digital representation of the city of Boston to profile whether different types of next-generation multimedia applications can be supported by the wireless network in new frequency bands of interest for 6G.
The data is publicly available at [36], and the code is open source under the MIT license and available at [37].As future work, we will leverage the BostonTwin framework to create realistic RT-based scenarios for the city of Boston in Colosseum, enabling full-stack twinning studies in cellular and wireless systems, and compare with real-world measurements for validation.In addition, we will embed a more advanced terrain model, including elevation, and integrate with mobility simulators such as SUMO.

Figure 3 :
Figure 3: LOD of the building models in the central area of Boston.

Figure 4 :
Figure 4: The workflow for the Boston Twin.

Figure 5 :
Figure 5: Coverage map for the central area of Boston in terms of Signal-to-Noise-Ratio (SNR) (a) and throughput requirements for XR (b) and extended sensors in V2X (c).In the latter two maps, the green areas indicate where the requirements are satisfied.

Table 1 :
Location and 3D model information for the tiles covering the central area of Boston.

Table 2 :
Level of Detail (LOD) as defined by the citySchema format.According to the citySchema format, each model has a different Level of Detail (LOD).The definition of the different LODs of the standard are reported in Table reported in Table 1.For each tile, different data formats for the 3D models are available, e.g., OBJ Waveform and Sketchup files, and a Model Catalog in Comma Separated Values (CSV).While the building coordinates in the Model Catalog are expressed as (Longitude, Latitude), following the World Geodetic System 1984 (WGS84), or EPSG:4326 reference, the OBJ models use a custom Coordinate Reference System (CRS), as reported in the BPDA documentation.In particular, the Massachusetts State Plane in feet is employed as the geographical projection plane, with North American Datum 1983 (NAD 83) and North American Vertical Datum 1988 (NADV 88) as Horizontal and Vertical Datum, respectively.The origin of the custom CRS is then set at (731100, 2902900) feet of the Massachusetts State Plane (WGS84: (Longitude: 71.223391 W, Latitude: 42.213379 N)).

Table 3 :
Network and ray-tracing parameters used to obtain the coverage maps.