Nr module (5G LENA) - desynchronised antennas: from ICI to CLI - Problem with SINR and ICI

25 views
Skip to first unread message

Stefano Biccari

unread,
Dec 13, 2025, 8:55:32 AM (3 days ago) Dec 13
to ns-3-users
Hello everyone,

I'm new here so... nice to meet you. My idea would be to create a 5G simulation environment whit NR module (5G-LENA) where we can study the interference effects in the case of desynchronised antennas operating at the same frequency. The ns3 versione that I'm using is 3.45.

I tried to create a simplified basic structure for this, where there are two GNBs, each connected to a UE, which are then connected to the EPC and a remote server. In this simulation, I created both uplink and downlink traffic. Through the flow helper, I saw that the packets reach their destinations, so from a macroscopic point of view, it seems to work.
My goal at this stage is not yet to manage desynchronisation but to actually see that ICI is being managed. However, when I check the NR traces, particularly those relating to SINR, I see that it remains fixed at each transmission, which I would have expected to change based on the interfering moments of ICI between the two UEs and the two GNBs.

I realise that at the moment I am not yet managing a situation of desynchronised antennas, but my idea is to take it step by step. I don't know if a real situation of desynchronised antennas is actually feasible in ns3, but I have seen that there is the possibility among the settable parameters to set the TTD pattern, so my idea was then, once I understood how to fix the ICI and SINR issue, to set the two TTDs of the antennas as if they were out of phase by one slot and start to see what happens, such as DDDUD and DDDDU.

I have included my simulation code below, in case anyone with experience can spot any logical or implementation errors.


Since I'm here, I'll give you a preview of the tests I've done, in case you're interested. I added the option to enable beamforming, as I wanted to see if it would improve the number of lost packets, and spoiler alert: yes, it turns out that when I enable it, I no longer have any losses. However, I justified this because I have a large increase in gain, which increases the SINR, and since the packet drop is linked to this, they are probably no longer dropped. Another thing I am unsure about is the reason for the drop: whether they are lost in the air or whether they are received and then dropped.


Changing the distance of the UEs only changes the SINR of the individual UE, and not that of the other, as if the interference were not seen. Depending on how the distance is changed, the packet drop of the UE also changes, which makes sense if the loss on free space is working.


I hope I have been as clear as possible and that someone can help me in some way. But regardless, to you who are reading this, I thank you for taking the time to read it!


I look forward to any updates, and in the meantime, I will continue to work on it.

desinc-v5.cc

Gabriel Ferreira

unread,
Dec 14, 2025, 11:22:41 AM (2 days ago) Dec 14
to ns-3-users
I don't understand what you mean by desynchronized antennas.

Interference between different cells in same frequencies, we do support. 

For interference sources you can use PDSCH and/or CSI-IM. PDSCH alone only measures interference on used rgbs, which requires having data traffic to be able to measure anything significant. Full buffer if you want to measure entire bandwidth. CSI-IM on the other hand estimates wideband interference from other cells based on CSI-RS signals. 

Stefano Biccari

unread,
Dec 15, 2025, 1:29:26 PM (15 hours ago) Dec 15
to ns-3-users

First of all, thank you for your reply.


By desynchronised antennas, I mean antennas that do not have their TTD aligned, with possible partial slot overlaps and, consequently, the generation of CLI. What I want to see in my final result is how even small desynchronisations lead to degradation of 5G transmission.


But before thinking about the CLI situation, I thought it would be better to understand how the ICI situation was being handled.


As for my simulation, I think I took the approach you suggested, which is to saturate the PDSCH and PUSCH, and I did this by inserting a host that sends and receives 1000 packets, using UDP apps. At that point, my idea was to insert the simplest possible scenario, i.e. one with a GNB and a user connected to it (GNB1 - UE1) and another GNB with its UE connected (GNB2 - UE2). This was done in a UMa scenario, without BF, with isotropic antennas and a 3GPP channel. These antennas are 200 m apart (gnb1: 0;0;0 - gnb2 0;200;0) and I first tried to put the two UEs in the same spot (0;100;0) and they have -12.558 and -12.3736 dB as SINR. If I move UE towards gnb1 and I have a situation where UE1: 0;50;0 and UE2: 0;100;0, I expect both to improve because one gets closer, reducing path loss, and the other suffers less ICI interference. The values they obtain are SINR -11.205 and -12.3721.

So there has been an improvement, but it is practically imperceptible in terms of ICI. And so I was wondering if it made sense that, even though we were now moving away from it, the improvement was so fleeting.


Another test I did was to place the UE 1 exactly where the gnb2 was, so that all its power would interfere with the UE2. What I got was that the SINR of the UE2 rightly dropped to -21 dB, while that of the UE1 obviously dropped even further because it moved away, reaching -40 dB.


So I was also wondering if these values made sense to you and if there was anything you would set to try to visualise these values better. Oh, right, I should point out that this data was from the UL.


I also tried inserting BF, and when I do so, the situation improves, bringing the SINR above 8 dB. Here too, I am not satisfied because the ideal BF works for me, but when I put in the real one, it gives me “died <signal.SIGSEGV: 11>”.


Thank you again for your time!

Gabriel Ferreira

unread,
Dec 15, 2025, 5:23:19 PM (11 hours ago) Dec 15
to ns-3-users
I am still not quite sure what you mean by that. 

The TDD slots are aligned in time, since we do not model propagation delay nor local time innacuracies, which allowed us not to care about synchronization signalling/procedures. 

Regarding SINR, when using 3GPP channel, you cannot look at a single value, because it is stochastic. Collect sinr for UEs over time, then use a t-test to compare if distributions are statistically the same or are different. You can do it getting traces from received transport block traces.

Without the stacktrace of the real beamforming crash, I can't help much. 
Reply all
Reply to author
Forward
0 new messages