LAA Flow duration problem

[Vasilis]

Dear all,

I am experimenting with the LAA - WiFi coexistence module.

I am using UDP traffic. The OperatorA is set as WiFi and the operatorB is set as LAA.

I have separated the nodes of both operators so they don't interfere with each other. This is not something related to the problem but explains why at the attached phy_logs observed by node1 do not include WiFi transmissions and why the WiFi throughput is so high. 

I have noticed the following strange behaviour.

When I am sending traffic with a duration e.g. 30s the LAA flows report a transmission duration of ~18-20 seconds. The flow of WiFi reports a TX duration of ~ 30 s at is should be. The reported TX duration can vary a bit regarding the TXOP (in the presented results TXOP=8ms) but still is much lower than the transmissions reported in the phy_logs

In the phy_logs I can see that the LAA nodes send traffic until the end of the simulator. 

This strange behaviour also gives wrong throughput for the LAA flows.

Flow 1 (11.0.0.1:49153 -> 17.0.0.2:9) proto UDP

  Tx Packets: 279474

  Tx Bytes:   287299272

  TxOffered:  76.6131 Mbps

  Rx Bytes:   287299272

  Throughput: 77.0984 Mbps

  Mean delay:  0.760786 ms

  Mean jitter:  0.0706586 ms

  timeLastRxPacket: 32.0008 s

  timeFirstTxPacket: 2.18968 s

  rxduration: 29.8112 s

  Rx Packets: 279474

--------monitorB----------

Flow 1 (2.0.0.2:49153 -> 7.0.0.3:9) proto UDP

  Tx Packets: 277676

  Tx Bytes:   285450928

  TxOffered:  76.1202 Mbps

  Rx Bytes:   59424568

  Throughput: 25.6023 Mbps

  Mean delay:  5508.34 ms

  Mean jitter:  0.416442 ms

  timeLastRxPacket: 20.95 s

  timeFirstTxPacket: 2.38146 s

  rxduration: 18.5685 s

  Rx Packets: 57806

Flow 2 (2.0.0.2:49154 -> 7.0.0.2:9) proto UDP

  Tx Packets: 275891

  Tx Bytes:   283615948

  TxOffered:  75.6309 Mbps

  Rx Bytes:   59565404

  Throughput: 25.9486 Mbps

  Mean delay:  4899.64 ms

  Mean jitter:  0.402106 ms

  timeLastRxPacket: 20.936 s

  timeFirstTxPacket: 2.57186 s

  rxduration: 18.3641 s

  Rx Packets: 57943

Flow 3 (2.0.0.2:49155 -> 7.0.0.4:9) proto UDP

  Tx Packets: 274614

  Tx Bytes:   282303192

  TxOffered:  75.2809 Mbps

  Rx Bytes:   61965784

  Throughput: 24.4297 Mbps

  Mean delay:  5321.63 ms

  Mean jitter:  0.410801 ms

  timeLastRxPacket: 23 s

  timeFirstTxPacket: 2.70804 s

  rxduration: 20.292 s

  Rx Packets: 60278

Attached you can find the phy_logs observed by node1.

Moreover it does not matter which flow is set as LAA and which as WiFi. If I interchange the operators then I have the same behaviour for operatorA instead of operatorB.

I am using the latest version of the module. 

Am I missing something?

Many thanks in advance.

Kind regards,

Vasilis

[Tom Henderson]

> rxduration: *18.5685 s*

> Rx Packets: 57806
> Flow 2 (2.0.0.2:49154 -> 7.0.0.2:9) proto UDP
> Tx Packets: 275891
> Tx Bytes: 283615948
> TxOffered: 75.6309 Mbps
> Rx Bytes: 59565404
> Throughput: 25.9486 Mbps
> Mean delay: 4899.64 ms
> Mean jitter: 0.402106 ms
> timeLastRxPacket: 20.936 s
> timeFirstTxPacket: 2.57186 s

> rxduration: *18.3641 s*

> Rx Packets: 57943
> Flow 3 (2.0.0.2:49155 -> 7.0.0.4:9) proto UDP
> Tx Packets: 274614
> Tx Bytes: 282303192
> TxOffered: 75.2809 Mbps
> Rx Bytes: 61965784
> Throughput: 24.4297 Mbps
> Mean delay: 5321.63 ms
> Mean jitter: 0.410801 ms
> timeLastRxPacket: 23 s
> timeFirstTxPacket: 2.70804 s

> rxduration: *20.292 s*

> Rx Packets: 60278
> |
>
>
> Attached you can find the phy_logs observed by node1.
> Moreover it does not matter which flow is set as LAA and which as WiFi.
> If I interchange the operators then I have the same behaviour for
> operatorA instead of operatorB.
>
> I am using the latest version of the module.
>
> Am I missing something?

In general, this does not happen with LAA (e.g. ./waf --run
'laa-wifi-simple --duration=30'), so I think you will need to debug why
reception stops at some point. From the throughput numbers, it seems
like there must be a lot of packet loss also before 20s time.

- Tom

[Vasilis]

Hi Tom,

Thank you for your answer.

My tests are based on the laa-wifi-simple that it has been extended with the following topology:

  bsNodesA.Create (1);
  bsNodesB.Create (3);
  ueNodesA.Create (1);
  ueNodesB.Create (3);
  allWirelessNodes = NodeContainer (bsNodesA, bsNodesB, ueNodesA, ueNodesB);


  Ptr<ListPositionAllocator> positionAlloc = CreateObject<ListPositionAllocator> ();
  positionAlloc->Add (Vector (1000.0, 0.0, 0.0)); // AP0 in cell 0

  positionAlloc->Add (Vector (d2, 0.0, 0.0)); // eNB1 in cell 1
  positionAlloc->Add (Vector (0.0, 0.0, d2)); // eNB2 in cell 2
  positionAlloc->Add (Vector (-d2, 0.0, 0.0));   // eNB3 in cell 3
  positionAlloc->Add (Vector (1000.0, d1, 0.0));  // STA0 in cell 0
  positionAlloc->Add (Vector (d2, d1, 0.0));  // UE1 in cell 1
  positionAlloc->Add (Vector (0.0, d1, d2));  // UE2 in cell 2  
  positionAlloc->Add (Vector (-d2, d1, 0.0));  // UE3 in cell
 

Indeed when only one LAA is used in the flow the rx duration is correct. 

Moreover, if the 3 operators are not in the proximity of each other then the rx duration is again correct.

The problem occurs for more than one LAA per operator, in the proximity of each other. 

The rest of the code is the original one, using the last version: http://code.nsnam.org/laa/ns-3-lbt/

Best regards,

Vasilis

[Tom Henderson]

--
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.
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.

Hi Vasilis,

I made the change you listed above and ran

./waf --run 'laa-wifi-simple --duration=30'

and did not see the problem.  Perhaps you have other changes elsewhere?

Anyway, I think that you will need to debug this using logging statements or other means, looking for events around the times that you observed that IP flow monitor stopped seeing packets.

- Tom

[Vasilis]

Hi Tom,

Thank you very much again.

I downloaded again the whole code, built and run and I am still seeing the same results.

May I ask? Did you test the laa-wifi-simple using the default d1 and d2 values (d1=10 and d2=50)? Because in such a case possibly the LAA BS are not in the proximity of each other and they can reach the maximum throughput.

In my tests I used d1=10 and d2=10.

Attached you can find two files named "run-scenario.sh" and "1_wifi_3_laa.cc". The "run-scenario.sh" lists all the parameters used to configure the laa and wifi networks described in the "1_wifi_3_laa.cc". The "1_wifi_3_laa.cc" is under the scratch folder.

When I run the simulator (for 30sec) based on those files I am getting the following results:

Running simulation for 30 sec of data transfer; 34 sec overall

Operator A: Wi-Fi; number of cells 1; number of UEs 1

Operator B: LAA; number of cells 3; number of UEs 3

Total txop duration: 0 seconds.

Total phy arrivals duration: 0 seconds.

--------monitorA----------

Flow 1 (11.0.0.1:49153 -> 17.0.0.2:9)

proto UDP
  Tx Packets: 275891

  Tx Bytes:   283615948
  TxOffered:  75.6309 Mbps

  Rx Bytes:   283615948
  Throughput: 77.0987 Mbps
  Mean delay:  0.760652 ms
  Mean jitter:  0.0706557 ms
  timeLastRxPacket: 32.0007 s
  timeFirstTxPacket: 2.57186 s
  rxduration: 29.4289 s
  Rx Packets: 275891
--------monitorB----------
Flow 1 (2.0.0.2:49153 -> 7.0.0.2:9) proto UDP
  Tx Packets: 280814
  Tx Bytes:   288676792
  TxOffered:  76.9805 Mbps
  Rx Bytes:   62482868
  Throughput: 26.5049 Mbps
  Mean delay:  5127.15 ms
  Mean jitter:  0.386736 ms
  timeLastRxPacket: 20.906 s
  timeFirstTxPacket: 2.04672 s
  rxduration: 18.8593 s
  Rx Packets: 60781
Flow 2 (2.0.0.2:49154 -> 7.0.0.4:9) proto UDP
  Tx Packets: 279058
  Tx Bytes:   286871624
  TxOffered:  76.4991 Mbps
  Rx Bytes:   64256168
  Throughput: 27.5926 Mbps
  Mean delay:  5374.6 ms
  Mean jitter:  0.381374 ms
  timeLastRxPacket: 20.864 s
  timeFirstTxPacket: 2.23402 s
  rxduration: 18.63 s
  Rx Packets: 62506
Flow 3 (2.0.0.2:49155 -> 7.0.0.3:9) proto UDP
  Tx Packets: 279032
  Tx Bytes:   286844896
  TxOffered:  76.492 Mbps
  Rx Bytes:   61156748
  Throughput: 26.0752 Mbps
  Mean delay:  5367.82 ms
  Mean jitter:  0.389787 ms
  timeLastRxPacket: 21 s
  timeFirstTxPacket: 2.23683 s
  rxduration: 18.7632 s
  Rx Packets: 59491

Again the only changes that I have done to the fresh downloaded code is to output the timeLastRxPacket, timeFristTxPacket and rxduration values in the end of the simulation.

Sorry for my omission to mention the distances in the previous post.

Thank you very much again.

Best regards,

Vasilis

[Tom Henderson]

There are a number of statistics and logs that can be enabled (to see the list, you can pass the '--PrintGlobals' argument to the command line).  I suggest that you first try to run a scenario that gives good performance, and enable those logs and have a look at what a 'good' run looks like, then enable the same logs for your configuration and see what is different.

- Tom

[Vasilis]

Hi Tom,

Thank you a lot. Yes, I am quite familiar with NS3 and I have already tried to find the cause.

I just want to make sure that this is a general problem and not related to my setup. As I said I just used a fresh build of the code.

Could you please perhaps verify if you also get the same results in your setup using the settings I mentioned in my previous post?
Then maybe we can create a bug report related to this.

Many thanks,

Vasilis