Duty Cycle paramater impact at LTE-DC and Wifi coexistance performance

[pedro maia]

Hi everyone,

According to design documentation and scientific bibliography, for LBT or LTE-Duty Cycle functionality, Wifi no longer uses YansWifiPhy, instead it uses SpectrumWifiPhy to allow the reception for LTE signals as an interference. Futhermore, according to phase 2 code implementation, we can configure each cell to one of "Laa, Wifi, or Lte" and if choosing "Lte", it uses LTE duty cycle, and if we set the duty cycle to 1, you should basically get normal LTE on the downlink.

My question basically is: Normal LTE (duty-cyle = 1) theoretically should totally kill wifi, right? Well, our simulations and debugging experiments shows that Wifi doesn't keep at CCA Busy state and functions "normally" at LTE-DC (DC=1) presence. 

It was used the scenario "laa-wifi-indoor." ( with operator A: Wifi / operator B: Lte ) using an extreme case of 1 m distance for both d1 and d2, keeping the -62 dBm default Wifi energy detection.

Thanks in advance for any information. 

[Vinicius Dantas]

Same issue here, I am running:

./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15 --ChannelAccessManager=DutyCycle --lteDutyCycle=1 --d2=1 --d1=1'

Which gives me the ABS pattern 0000000000000000000000000000000000000000, while the throughput is:

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

  Throughput: 73.9803 Mbps

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

Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Throughput: 67.9634 Mbps

As running:

./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15 --ChannelAccessManager=DutyCycle --lteDutyCycle=0 --d2=1 --d1=1'

Gives me the pattern 1111011111111111111111111111111111111110 and the following throughput:

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

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:9) proto UDP

  Throughput: 1.77042 Mbps

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

Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Throughput: 77.0945 Mbps

It would be expected zero throughput for LTE for the first case, I am not sure why it doesn't happen.

[Vinicius Dantas]

It would be expected zero throughput for LTE for the second case, I mean.

[Biljana Bojović]

Hi Pedro Maia,

could you please clarify how to reproduce?

I do not understand the description of the scenario being used, because d1 and d2 are not parameters of laa-wifi-indoor, instead they are used in laa-wifi-simple.

Regarding your other question about effect of normal LTE on wifi, I agree that under those conditions it is expected that LTE heavily affects wifi, but please note that this will also depend on the traffic pattern.

Best regards,
Biljana

[Biljana Bojović]

Hi Vinicius Dantas,

please not that when lteDutyCycle is set to 0, not all subframes in the mask are set to be blank.  There are always 2 out of 40 subframes that are left to be non ABS, in order to allow transmission of CTRL messages. In these subframes DATA also can go through. Thus, I would say that any value of LTE throughput up to 3.75Mbps is expected  for the configuration when LTE duty cycle is 0.

If you have further questions related to this maybe you should open a new thread, since this seem to be different question from Pedro's.

Thanks,
Biljana

[viniciu...@gmail.com]

I actually see it as the same situation. I'm sorry for posting the wrong question again though, I was in rush.

I am surprised on how LTE does not kill the wifi in the first scenario, isn't the wifi aware of LTE's power when performing carrier sensing?

--
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 a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/tIOrowo0XO0/unsubscribe.
To unsubscribe from this group and all its topics, 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.

[Biljana Bojović]

Hi Vinicius,

yes, you are right, I didn't see that you were asking also about that case. I was just running now the simulation with the parameters that you provided :

./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15  --lteDutyCycle=1 --d2=1 --d1=1'

and I got the following results:

Running simulation for 15 sec of data transfer; 19 sec overall
Operator A: LTE; number of cells 1; number of UEs 1
Operator B: Wi-Fi; number of cells 1; number of UEs 1
LTE duty cycle: requested 1, actual 1, ABS pattern 0000000000000000000000000000000000000000
Total txop duration: 0 seconds.
Total phy arrivals duration: 0 seconds.

--------monitorA----------
Flow 1 (1.0.0.2:49153 -> 7.0.0.2:9) proto UDP

  Tx Packets: 138554
  Tx Bytes:   142433512
  TxOffered:  75.9645 Mbps
  Rx Bytes:   136735308
  Throughput: 74.0013 Mbps
  Mean delay:  3.5209 ms
  Mean jitter:  0.189622 ms
  Rx Packets: 133011

--------monitorB----------
Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Tx Packets: 136448
  Tx Bytes:   140268544
  TxOffered:  74.8099 Mbps
  Rx Bytes:   0
  Throughput:  0 Mbps
  Mean delay:  0 ms
  Mean jitter: 0 ms
  Rx Packets: 0

So, seems everything ok. Could you please provide me more info, e.g. which repository are you using, and which version? Did you make some modifications in the code?

Here is a brief explanation about ChannelAccessManager configuration option. I see you that you also configured it. This option is only used when cell is LAA, so in the case in which you are running, this option will be ignored.  This configuration option is added to allow to configure different channel access managers to LAA node.

The another parameter, --lteDutyCycle, is parameter that configures duty cycle that can be set to regular LTE (--cellConfig=Lte) and this duty cycle implementation is based on ABS pattern, while the DutyCycle channel access manager for LAA is implementing channel access manager interface.

We will try to provide more detailed information in the documentation soon.

Best regards,
Biljana

[Vinicius Dantas]

I am running them against http://code.nsnam.org/laa/ns-3-lbt/ 's head. 

I just tested recloning and running: same results. Should I use another repository? I thought this one was the official one for LTE coexistence.

To unsubscribe from this group and all its topics, 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.

--

Vinícius Dantas de Lima Melo
Graduando em Ciências e Tecnologia 
Universidade Federal do Rio Grande do Norte (UFRN)
Escola de Ciências e Tecnologia (ECT)
Natal, Rio Grande do Norte
viniciu...@gmail.com viniciu...@bct.ect.ufrn.br vinicius.dan...@mail.utoronto.ca | Celular/Mobile Phone: +1 647 447 5737

Skype: viniciusdantas01

[Biljana Bojovic]

You are using the correct repository.

Thank you very much for trying again and detecting this issue. This looks like bug. Seems that something got broke in calculation of wifi performance in some of the latest updates of the code.

We will check this and provide some feedback promptly.

viniciu...@gmail.com viniciu...@bct.ect.ufrn.br vinicius.dantasdelimamelo@mail.utoronto.ca | Celular/Mobile Phone: +1 647 447 5737

Skype: viniciusdantas01

--

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.

[Vinicius Dantas]

Against which version/parent are you running? I would like to help looking for the issue.

viniciu...@gmail.com viniciu...@bct.ect.ufrn.br vinicius.dan...@mail.utoronto.ca | Celular/Mobile Phone: +1 647 447 5737

Skype: viniciusdantas01

[Biljana Bojovic]

Would be good to check first flow-monitor stats in scenario-helper.

[Vinicius Dantas]

Running:

./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15  --lteDutyCycle=1 --d2=1 --d1=1'

Got the stats:

Total txop duration: 0 seconds.

Total phy arrivals duration: 0 seconds.

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

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:9) proto UDP

  Tx Packets: 133296

  Tx Bytes:   137028288

  TxOffered:  73.0818 Mbps

  Rx Bytes:   131509984

  Throughput: 73.9803 Mbps

  Mean delay:  3.52672 ms

  Mean jitter:  0.189602 ms

  Rx Packets: 127928

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

Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Tx Packets: 134633

  Tx Bytes:   138402724

  TxOffered:  73.8148 Mbps

  Rx Bytes:   1221264

  Throughput: 67.9634 Mbps

  Mean delay:  12.1278 ms

  Mean jitter:  0.192116 ms

  Rx Packets: 1188

viniciu...@gmail.com viniciu...@bct.ect.ufrn.br vinicius.dan...@mail.utoronto.ca | Celular/Mobile Phone: +1 647 447 5737

Skype: viniciusdantas01

[Tom Henderson]

Hi Vinicius,
Here is what is happening in the above.  You are observing 1188 packets get through on Wi-Fi despite LTE being on.  The simulation is running for 15 seconds of data capture, after 2 seconds of network warmup.  However, in the first second of data transfer, we stagger start the applications, and in this case, Wi-Fi's application is getting a head start on LTE's application.

If you examine an ascii trace of the packets received on the WiFi STA, the first one is received at time 2.6394 and the last at 2.78399, but then no more get through until the end of the simulation.  This is because the Wi-Fi UdpClient app started a short bit before the LTE UdpClient.  Both will start at a time uniformly distributed between 2 seconds and 3 seconds, in this case, due to this code:

ApplicationContainer
ConfigureUdpClients (NodeContainer client, Ipv4InterfaceContainer servers, Time startTime, Time stopTime, Time interval)
{
  // Randomly distribute the start times
  Ptr<UniformRandomVariable> randomVariable = CreateObject<UniformRandomVariable> ();
  randomVariable->SetAttribute ("Max", DoubleValue (1.0));
  ...
  clientApps.StartWithJitter (startTime, randomVariable);


if you vary the RngRun variable, you will get outcomes in which LTE starts before Wi-Fi, and then Wi-Fi will not get any packets through.  For instance, try:

./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15  --lteDutyCycle=1 --d2=1 --d1=1 --RngRun=2'

and you will see:

--------monitorB----------
Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Tx Packets: 133880
  Tx Bytes:   137628640
  TxOffered:  73.4019 Mbps

  Rx Bytes:   0
  Throughput:  0 Mbps
  Mean delay:  0 ms
  Mean jitter: 0 ms
  Rx Packets: 0

The other statistic that may look off is the Wi-Fi throughput from above:

     Throughput: 67.9634 Mbps

This may seem off due to the way that the throughput is calculated, which is the total number of bytes observed divided by the time difference between the last and first packet observed.

This is because of the nature of how throughput is calculated, looking at the bytes observed over the duration of the flow.  Here, the duration of the flow as perceived by FlowMonitor is very short (2.78399s-2.6394s = 0.14459 sec) and 1221264 bytes observed during this interval corresponds to ~68 Mbps.  In brief, the Wi-Fi application does manage to sustain a high rate for a very brief time before LTE turns on.

- Tom

[pedro maia]

Dear all,

Thank you for your reply.

I kept the investigation going on and for the same scenario you described with d2=1000 

(./waf --run laa-wifi-simple --command='%s --cellConfigA=Lte --cellConfigB=Wifi --duration=15  --lteDutyCycle=1 --d2=1000 --d1=10 --RngRun=2'), 

In which we expected WIFI to transmit since there's no interference between both systems anymore. However, the results still were:

Operator A: LTE; number of cells 1; number of UEs 1

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

LTE duty cycle: requested 1, actual 1, ABS pattern 0000000000000000000000000000000000000000

Total txop duration: 0 seconds.

Total phy arrivals duration: 0 seconds.

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

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:9) proto UDP

  Tx Packets: 74749

  Tx Bytes:   76841972

  TxOffered:  76.842 Mbps

  Rx Bytes:   73767224

  Throughput: 73.9883 Mbps

  Mean delay:  3.52084 ms

  Mean jitter:  0.189626 ms

  Rx Packets: 71758

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

Flow 1 (12.0.0.1:49153 -> 18.0.0.2:9) proto UDP

  Tx Packets: 68254

  Tx Bytes:   70165112

  TxOffered:  70.1651 Mbps

  Rx Bytes:   0

  Throughput:  0 Mbps

  Mean delay:  0 ms

  Mean jitter: 0 ms

  Rx Packets: 0

As you recomended, I analyzed the ascii wifi trace files for two cases:

case 1: ./waf --run scratch/laa-wifi-simple --command="%s  --d2=1000 --d1=10 --cellConfigB=Wifi --cellConfigA=Lte --RngRun=2 --duration=8 --lteDutyCycle=1 --wifiQueueMaxSize=2000 --asciiEnabled=1"

case 2: ./waf --run scratch/laa-wifi-simple --command="%s  --d2=1000 --d1=10 --cellConfigB=Wifi --cellConfigA=Lte --RngRun=3 --duration=8 --lteDutyCycle=1 --wifiQueueMaxSize=2000 --asciiEnabled=1"

I've noticed that for RngRun=2 something strange happens at the time t=2.00993, where the next log happens only at t=10.0033, like:

- t 2.00993 ns3::WifiMacHeader (MGT_BEACON ToDS=0, FromDS=0, MoreFrag=0, Retry=0, MoreData=0 Duration/ID=0us, DA=ff:ff:ff:ff:ff:ff, SA=00:00:00:00:00:06, BSSID=00:00:00:00:00:06, FragNumber=0, SeqNumber=22) ns3::MgtProbeResponseHeader (ssid=ns380211n-B, rates=[*0mbs *6mbs *12mbs *24mbs], DSSS Parameter Set= , ERP information=0|0|0, HT Capabilities=0|0|0|0 , HT Operations=0|0|0 , VHT Capabilities= 0|0) ns3::WifiMacTrailer ()

- t 10.0033 ns3::WifiMacHeader (MGT_BEACON ToDS=0, FromDS=0, MoreFrag=0, Retry=0, MoreData=0 Duration/ID=0us, DA=ff:ff:ff:ff:ff:ff, SA=00:00:00:00:00:06, BSSID=00:00:00:00:00:06, FragNumber=0, SeqNumber=23) ns3::MgtProbeResponseHeader (ssid=ns380211n-B, rates=[*0mbs *6mbs *12mbs *24mbs], DSSS Parameter Set= , ERP information=0|0|0, HT Capabilities=0|0|0|0 , HT Operations=0|0|0 , VHT Capabilities= 0|0) ns3::WifiMacTrailer ()

However, for RngRun=3, everything goes normal and Wifi transmits all the time.

I would like to know some suggestion about how I can investigate more precisally what is happening.

Full trace files are attached.

--
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 a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/tIOrowo0XO0/unsubscribe.
To unsubscribe from this group and all its topics, 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.

--

MAIA DE SANTANA Pedro 

Electrical / Telecommunication Engineer

Wireless Communication Researcher of GppCom R&D

Contact:

Skype: pedro_maia02

Phone: +55 84 999341719

Natal, Rio Grande do Norte, Brazil - 59086-005