something weird about the handle of a packet at WifiAp node for laa+wifi and wifi +wifi scenario

32 views
Skip to first unread message

John Young

unread,
Oct 24, 2016, 10:18:04 PM10/24/16
to ns-3-users
In wifi+wifi scenario, when the client sends a downlink packet out. The ap receives and forwards it up to its wifiNetDevice to send it.
However, I find it weird that in laa +wifi scenario, the packet would not (or perhaps can not ?) be sent to wifinetDevice.  The  simulation is done in lbt laa-wifi-indoor scenario.

Tom Henderson

unread,
Oct 25, 2016, 12:07:21 AM10/25/16
to ns-3-...@googlegroups.com
Hi, I'm sorry but I can't give much feedback on this based on the
description. Can you send details that I could try to reproduce easily?

- Tom
Message has been deleted

John Young

unread,
Oct 25, 2016, 12:40:13 AM10/25/16
to ns-3-users
Yes. Thanks. It  results from my motivation to observe EdcaTxopN.  In laa+wifi scenario where laa uses channelManager "Default", and udp traffic type is transported, I hope to see packets are held up in wifiAp's queue and can not be sent till being dropped, or maybe their waiting time to be longer. However, I do not even find the packets goes into the queue.  And I try to figure it out with Log. I find that for laa+wifi scenario, after Node::ReceiveFromDevice() is called, WifiNetDevice::Send() is not invoked, which is invoked in wifi+wifi scenario. 

I'm not sure if I make it clear or provide useful information to reproduce it.

在 2016年10月25日星期二 UTC+8下午12:07:21,Tom Henderson写道:

Tom Henderson

unread,
Oct 25, 2016, 12:48:23 AM10/25/16
to ns-3-...@googlegroups.com
On 10/24/2016 09:36 PM, John Young wrote:
> Yes. Thanks. It results from my motivation to observe EdcaTxopN. In
> laa+wifi scenario where laa uses channelManager "Default", and udp
> traffic type is transported, I hope to see packets are held up in
> wifiAp's queue and can not be sent till being dropped, or maybe their
> waiting time to be longer. However, I do not even find the packets goes
> into the queue. And I try to figure it out with Log. I find that for
> laa+wifi scenario, after Node::ReceiveFromDevice() is called,
> WifiNetDevice::Send() is not invoked, which happens in wifi+wifi scenario.
>
> I'm not sure if I make it clear or provide useful information to
> reproduce it.

You seem to be saying for a certain WiFi AP in one operator network,
when the other operator network is WiFi, you observe
WifiNetDevice::Send() log statements on that AP, but when you change the
other operator network to LAA, the same WiFi AP does not exhibit
WifiNetDevice::Send () log messages anymore?

Perhaps the messages do not get forwarded from the IP layer because ARP
resolution failed? I think that you need to trace via debugging or
logging whether the packets get through the Ipv4L3Protocol, ArpCache,
ArpL3Protocol, Ipv4Interface objects if you do not see them showing up
on WifiNetDevice.

- Tom

John Young

unread,
Oct 25, 2016, 12:54:45 AM10/25/16
to ns-3-users
Ok, thanks, I'm debugging it.

在 2016年10月25日星期二 UTC+8下午12:48:23,Tom Henderson写道:

John Young

unread,
Oct 25, 2016, 6:54:46 AM10/25/16
to ns-3-users
Yes, you are right. It seems the ping packet transmission is interfered by laa, and arp information may not be timely obtained. And if I start ping apps earlier and extends its duration before the data comes in scenarioHelper.cc, it will be ok. Before the change, sta receives no packet. And after that, it can receive more than 400 ones.   

在 2016年10月25日星期二 UTC+8下午12:48:23,Tom Henderson写道:
On 10/24/2016 09:36 PM, John Young wrote:
Reply all
Reply to author
Forward
Message has been deleted
0 new messages