RT data structure

[PhilSoy]

In my simulation, I have 1 transmitter and 12 receivers. Sionna calculates 534 paths. I need to determine the source and target of each path, as well as the number and type of each interaction. but do not understand the data structure, especially for what concerns paths.type. Here are the shapes of some parameters: a shape : (1, 12, 1, 1, 1, 534, 1) tau shape : (1, 12, 1, 534) types shape : (1, 534) theta_t shape : (1, 12, 1, 534) targets shape : (12, 3) vertices shape: (5, 12, 1, 534, 3) *** mask shape : (1, 12, 1, 534) The paths.type should be an attribute of each path (similarly to Tau, DoA, and DoD), but it has only 2 dimensions. I understood initially that Sionna calculates a TOTAL of 534 paths (for all receivers combined), but this becomes inconsistent with the other parameters which indicates that 534 paths are calculated for EACH receiver. I also noticed that some paths.tau equal -1 Can you please explain the data structure ?

[faycalaa]

Hi @PhilSoy

• The type of a path is shared by all links, i.e., pairs of transmit-receive antennas. Therefore, in your setup, types[0,path_index] gives the type of the path with index path_index for all the receivers.

• Delays are set to -1 for paths that do not exist for the corresponding links. Therefore, delays equal to -1 should correspond to paths with corresponding entries in mask set to False. For these paths, the channel coefficient a should be zero. This is because some links might have less than 534 paths, and -1 is then used for padding. Note that because the corresponding channel coefficients are set to zero, this padding have no impact when computing, e.g., channel frequency responses from the traced channel impulse responses. Moreover, note that if you only need a subset of types (e.g., only LoS), you can enable/disable the corresponding flags in Scene.compute_paths.

Also, please note that the tensors targets and vertices are undocumented. This is because their shape differ from the other documented tensors in the following ways:

• They don't have a leading batch dimension of size one, which is added to the documented tensors to ensure compatibility with the other components of Sionna
• When using non-synthetic arrays, every transmit (receive) antenna is considered to be a source (target) of rays, which explains why the dimensions [num_rx, num_rx_ant] and [num_tx, num_tx_ant] are replaced by the [num_targets] and [num_sources] dimensions, respectively.
• The vertices tensor has a leading dimension that corresponds to the maximum number of interactions of the rays with the scene (max_depth), as this tensor provides the interaction point for every ray and for every bounce.

[PhilSoy]

I still do not understand the data structure. A path has the following attributes:

• Source, Target, DoD, DoA, A, Tau
• List of interactions
  • Depth 0: R/T/D/S, Object Id, coordinates of the hit point
  • Depth 1: R/T/D/S, Object Id, coordinates of the hit point
  • etc... Vertices gives the coordinates of the hit point for each quadruplet (Depth, Tx, Rx, Path), but the interaction type and the object Id are missing (I found the description of vertices in the source code). A path 'history' comprises several kinds of interactions with different objects. I don't know what to do with your types[0,path_index] as I don't understand what it designates

[jhoydis]

Hi @PhilSoy,

You must understand that a path in Sionna RT can only consist of the following interaction types :

1) LoS 2) Up to max_depth specular reflections 3) Up to max_depth-1 specular reflections followed by a diffuse reflection 4) A single diffraction

Thus, we do not need to report for every interaction its type. Please see also #276.

[PhilSoy]

This is a limitation for sensing, but I recognize that multiple diffuse reflections result in very small intensity can be neglected in most case.

One question remains open. Since there is a single paths.type attribute per path, does it correspond to the first interaction, or to the last one ?

[faycalaa]

The value of the types property is set as follows:

• Type = 0 --> LoS
• Type = 1 --> Only specular reflections (up to max_depth reflections)
• Type = 2 --> A single diffraction
• Type = 3 --> Up to max_depth-1 specular reflections followed by a diffuse reflection

[PhilSoy]

Thanks, this answers my question. Are there any evolution planned of the RT engine ?. I think that these limitations make Sionna not usable for sensing. Indeed: diffuse-->specular, and diffuse-->diffuse paths would be needed to model phenomenon like on this photo File:Eiffel Tower under cloudy sky.jpg - Wikipediahttps://en.wikipedia.org/wiki/File:Eiffel_Tower_under_cloudy_sky.jpg. This kind of Ghost targets (reversed Eiffel tower) would never happen with the current RT engine. Similarly diffuse to diffuse paths cannot be ignored (e.g. moonight)

[jhoydis]

We have not planned to add these types of interactions for now. The main reason being speed.

Can you explain why you need higher-order diffuse reflections for sensing applications?

Higher-order diffuse reflections will lead in many cases to very weak paths because the pathloss is proportional to the square of the product of the distances between interaction points and not the square of their sums as for purely specular paths.

[PhilSoy]

The highest priority would be to support paths experiencing diffusion followed by a specular reflection (creates ghost targets. Ref. my example with the Eiffel tower) Diffuse to diffuse is also desirable: this is the case of signal reflecting on the walls and then illuminating targets Transmission would also be useful, as most material are permeable.