spectrum: 3GPP channel model to support multiple antenna arrays per RX/TX device
This MR extends ThreeGppSpectrumPropagationLossModel and ThreeGppChannelModel to support collocated antenna arrays per device (or array subpartitions).
Firstly, this MR splits the channel params into those that are common per node pair and those that are specific for the antenna array pair. For example, if the TX and the RX node have multiple collocated antenna arrays, then there will be multiple channel matrices among the same pair of nodes for the different pairs of 3GPP antenna array of the TX and RX. These channel matrices that are among the same pair of nodes have some channel parameters in common, i.e., they share the same channel condition, cluster powers, cluster delays, AoD, AoA, ZoD, ZoA, K_factor, delay spread, etc. On the other hand, each pair of TX-RX antenna arrays has a specific channel matrix and fading, which depends on the actual antenna element positions and field patterns of each pair of antennas array subpartitions. To support that, we have split the GetNewChannel function into GetNewChannelParams and GetNewChannelMatrix, which update the respective (common and individual) parameters. Accordingly, the channel parameters are saved into two separate structures (ChannelParams - per node pair and ChannelMatrix - per antenna array pair). This change made to 3GPP channel model is generalizing its previous functionality, i.e., more antenna arrays are permitted per device and SpectrumChannel, but if the user configures a single antenna array the 3GPP channel model calculations (implemented in ThreeGppSpectrumPropagationLossModel and ThreeGppSpectrumChannel) should give the same results as before this MR. So, what is different is the organization of the channel information which is now split into two structures, and so the function that was previously generating a single structure now is divided into two independent functions.
Secondly, to allow multiple antenna arrays per device (and per SpectrumChannel instance), we needed to extend the spectrum module to support passing the TX and RX antenna arrays objects to the spectrum propagation loss models that require pointers to TX and RX antenna array objects in order to calculate RX PSD, like e.g. ThreeGppSpectrumPropagationLossModel, which needs e.g. BF vectors to calculate RX PSD. We have created a new type of spectrum propagation loss model interface called PhasedArraySpectrumPropagationLossModel, which is different from the already existing SpectrumPropagationLossModel because its function CalcRxPowerSpectralDensity needs to have as input also the PhasedArrayModel object of the TX and RX in order to calculate the RX PSD, i.e., it is not enough for these type of models just to pass the TX PSD and the mobility models of the TX and RX node, as it is for SpectrumPropagationLossModel types of models. ThreeGppSpectrumPropagationLossModel inherits this new interface. Due to this API change, the modules that use this ThreeGppSpectrumPropagationLossModel will just need to make sure that the SpectrumPhy::GetAnntenna function is correctly overridden in their module to return the PhasedAntennaArray corresponding to that SpectrumPhy instance.
Notice that, by adding this very simple design change into the spectrum model, we have removed a hard limitation of ThreeGppSpectrumPropagationLossModel which was to have a maximum of 1 antenna array instance per device (and per SpectrumChannel instance).
Also, to support the passing of the PhasedArrayModel pointers, we have made SpectrumPhy more generic by allowing it to support the PhasedArrayModel type of antenna and not only AntennaModel types, i.e., to achieve this we have modified the return type of SpectrumPhy::GetRxAntenna to be Ptr<Object> because Object is a common parent of AntennaModel and PhasedArrayModel, so GetRxAntenna can now return PhasedArrayModel, and not only AntennaModel as before. We have also considered it appropriate to change the name of the GetRxAntenna to GetAntenna, to reflect its meaning, because this antenna, in general, can be used for both transmission and reception.
We believe that this MR is very valuable because it can be used to implement MIMO through dual-polarized antennas (two collocated antenna sub-arrays, as we have done in the 5G-LENA module and which will be released soon). This framework can be used also for MU-MIMO implementation, by considering multiple subarrays to send streams towards different users through the array subpartition concept. Furthermore, it could enable the hybrid C-RAN architecture, with a gNB node controlling multiple radio units (subarrays that can be non-collocated), but for this also changes in the NR module, as for MU-MIMO, would be needed, and maybe also extensions of the current framework to allow for varying parameters per radio unit.