FIX(simulation): imt bs beamsteering angles

[artistrea]

This PR guarantees IMT azimuth angles are in [-180, 180) range.

fixes #202

The incorrect behavior of beamforming angle was introduced with the horizontal_beamsteering_range parameter.

We probably should include this bugfix in v1.0.1 #207

Bug specifics

At first we suspected that it was simply a problem of wrapping around the bs azimuth. However, there is still a bug present after fixing this. The beamsteering angle clipping was still wrong.

For example when bs azimuth = -180 a bug would still happen.
Consider azim = -180 and beamsteering range = [-60, 60]
Then beamsteering limits are -240, -120. That means they also need wrap around behavior.But after wrapping them around there still is a problem:
new range = 120, -120

np.clip does not behave correctly with this kind of range. Angle clipping should consider this wrap around behavior, and always clip to the closest angle limit.

For the vertical beamsteering the current implementation already works correctly. The elevations come from arccos, so it is always in the [0, 180] range. The beamsteering limits are also in the same range, with a_min < a_max always, so np.clip is appropriate.
The same cannot be said for a range that wraps around (e.g. a 2deg range from 179 to -179).

Impact estimation

All simulations with beamsteering ran in a branch with the commit 0020d8023ee869c3459a7a661d9146c17d386706 or any other commit that permits setting horizontal_beamsteering_range parameter for BS may have been affected. If the previous statement applies, your simulation has been affected if macrocell or hotspot IMT BS is used.

Para macrocell o impacto é:
considerando AZIMUTH = [60, 180, 300]

• A com 60 graus não é afetada, pois suas UE's estão sempre em 0 a 120, e o beamsteering limit vai limitar exatamente isso.
• A com 180 graus começa a ser afetada. Suas UE's estão em 120 a 180 e -120 a -180;
  • Se não for dado limite horizontal, ele é de 180 + [-180, 180]. Ou seja, de 0 a 360. Se for dado como [-60, 60] os limites vão de 120 a 240.
    • Então por exemplo um steering pra região de -120 a -180 na verdade acaba apontando para o limite inferior, que pode ser 0 ou 120 a depender da simulação ter passado o parâmetro ou não.
• Semelhante para o caso apontando para 300. Suas UEs estão em -120 a 0.
  • Se não passado o parâmetro, os limites vão de 120 a 480. Se passado [-60, 60], vão de 240 a 360;
    • Todas as UEs acabam sendo clipados para o limite inferior, que pode ser 120 ou 240.

Para hotspot o impacto é mais aleatório, mas cada BS segue a mesma lógica em relação a ser afetada ou não.
considerando que candidate_azimuth = 360 * random_number_gen.rand(1)
Então o azimute pode ir de 0 a 360, de forma uniforme.

• Azimute entre 0 e 120 não tem funcionamento afetado, pois a distribuição de UE (-60, 60) + 0...60 é sempre coberta pelo limite de beamsteering.
• O problema começa quando começa a ocorrer wrap around, a partir de 120 quando se passa limite (-60, 60) e a partir de 150 quando não se passa.
  • Por exemplo, com azim da BS em 121 o UE pode estar de 121 a 180, e de -180 a -179. Esse ângulo negativo não é coberto pelos limites de beamsteering 121 + (-60, 60), mas é coberto por 121 + (-180, 180)
• A partir de 240 todos os beams apontam para BS azim + lim_inf, sendo lim_inf -180. Ou -60 caso o parâmetro seja declarado.

Ou seja, a não utilização de limites beamsteering em uma simulação feita em ambiente problemático foi mais grave, pois os beams podiam passar a apontar para o azimute - 180, ou seja, diretamente para trás da BS.

No entanto, caso o parâmetro tenha sido passado corretamente, igual a (-60, 60), o impacto é menos grave, tendo funcionamento normal garantido em 1/3 dos casos, apontamento definido em azimute - 60 para 1/3 dos casos, e o outro 1/3 tendo comportamento misto (mais análise necessária para determinar o comportamento desse 1/3).
Pode-se dizer que é menos grave pois para os cálculos realizados, o que ocorreu é um viés para a antena apontar para a sua direita.