LBT Wifi coexistence Proportional Fair algorithm issue

51 views
Skip to first unread message

Pablo Campos

unread,
Oct 18, 2018, 7:06:31 AM10/18/18
to ns-3-users
Hi NS3 guys.

At first thank you for such nice and good simulation tool.

Second, I believe that I've found a bug in the proportional fair algorithm that is employed on LTE/Wi-Fi coexistence module, in specific.

SO: Ubuntu16
Source Code: ns-3-lbt-f88bdc99a277 (NS3.24)
Module: pf-ff-mac-scheduler.cc

Problem:

The problem appears in the proportional fair module when LBT is enabled during high collisions afecting to UEs.
Basically the scheduler assigns RBs based on the CQI reported back from UE to eNB. Sometimes, when UE is facing strong collisions (Hidden Node case), the CQIs indexes reported by UE can be 0 when both nodesBs (in hidden condition) transmit simultaneously and also after a time can be higher than 0 when only one nodeB transmits. In this scenario the scheduler does not assigns RBs to UE when CQI=0 but when CQI becomes != 0, the scheduler assigns RBs to this UE. The bug appears when exist many TBs that have to be retransmitted and are waiting until the scheduler receives a CQI != 0, in this case as soon as the scheduler receives a CQI!=0, it assigns RBs to UE during that specific 1 ms. The PF algorithm allows the retransmission of the last TB and the other TBs repressed in the queue so it is possible to transmit more bytes than physically the scheduler can transmit in 1ms using the best MCS. So during this 1 ms the scheduler sends all the TB repressed. This situation generates big differences between the number of bytes tx and rx at physical layer and number of bytes tx and rx in RLC level, this problem appears as stated when UE is facing hidden node problem, high SINR variations with medium to high traffic loads such as (2 or more files/seconds fileSize 2MB).

Solution:
The solution that worked for me is to allow the retransmission of the last TB that has to be retransmitted and drop the other TBs. This resolves the inconsistency in bytes between physical, mac and rlc layer and allow the RLC reach normal values of throughput also improves delay RLC problems that maybe can be associated to the issue described in:
 

See the attached documents to get a better idea of the issue and the results of my solution.

Can you provide some comments about this?

Best Regards.

Pablo Campos.
PF Mac algorithm issue.pdf
pf-mac-solution.txt
Reply all
Reply to author
Forward
0 new messages