question about the queueSize in laa wifi coexistence

[John Young]

In coexistence scenario, rlc MaxQueueSize and wifiMaxQueueSize are both set to 2000. However, in lbt-access-manager imple2, mac would be triggered at every subframe, and the packets would be piled up in phy where no limit exists. Thus rlcMaxQueueSize seems not take effect for ftp transmissions. For the sake of fair comparison, should I enlarge the queue size so that no packet drop is possilbe? 

Thanks.

[Biljana Bojović]

Hi John,

in normal operation of e.g. laa-wifi-indoor with ftp traffic there should not be any packet drops due to queue overflow. You are right about LTE phy, and LteRlcUm buffer is set to be large enough to accept file transfers. The similar situation is with wi-fi queue size, 2000 packet is enough to serve around 5-6 files transfers at the same time.

Can you be more specific in which scenario and with which configuration parameters you find that there are packet drops due to queue overflow? 

You might probably find the drops with high-rate UDP CBR traffic, and in that case I agree with you, you should probably try to adjust the queue size at both LTE and WIFI.

Cheers,
Biljana

[John Young]

Thanks a lot for your reply. I configured each sta with a independent app stream and the queue size for each ap was not enough. And thanks for your suggestion. I have adjusted the queue size for this case.

在 2016年11月17日星期四 UTC+8上午2:01:31，Biljana Bojović写道：

[Biljana Bojovic]

Ok, when adjusting, please note that in LTE, RLC queue is per flow and not per eNb, which is different from wifi MAC queue which is per AP.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+unsubscribe@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[John Young]

Oh, I did not notice it. Thanks for reminding me~

在 2016年11月17日星期四 UTC+8下午4:19:11，Biljana Bojović写道：

Ok, when adjusting, please note that in LTE, RLC queue is per flow and not per eNb, which is different from wifi MAC queue which is per AP.

On Thu, Nov 17, 2016 at 2:14 AM, John Young <plyang...@gmail.com> wrote:

Thanks a lot for your reply. I configured each sta with a independent app stream and the queue size for each ap was not enough. And thanks for your suggestion. I have adjusted the queue size for this case.

在 2016年11月17日星期四 UTC+8上午2:01:31，Biljana Bojović写道：

Hi John,

in normal operation of e.g. laa-wifi-indoor with ftp traffic there should not be any packet drops due to queue overflow. You are right about LTE phy, and LteRlcUm buffer is set to be large enough to accept file transfers. The similar situation is with wi-fi queue size, 2000 packet is enough to serve around 5-6 files transfers at the same time.

Can you be more specific in which scenario and with which configuration parameters you find that there are packet drops due to queue overflow? 

You might probably find the drops with high-rate UDP CBR traffic, and in that case I agree with you, you should probably try to adjust the queue size at both LTE and WIFI.

Cheers,
Biljana



On Tuesday, November 15, 2016 at 2:25:00 AM UTC+1, John Young wrote:

In coexistence scenario, rlc MaxQueueSize and wifiMaxQueueSize are both set to 2000. However, in lbt-access-manager imple2, mac would be triggered at every subframe, and the packets would be piled up in phy where no limit exists. Thus rlcMaxQueueSize seems not take effect for ftp transmissions. For the sake of fair comparison, should I enlarge the queue size so that no packet drop is possilbe? 

Thanks.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.