Vasilis
Apr 19, 2017, 12:01:15 PM4/19/17
to ns-3-users
Hello everybody,
I am trying to study a scenario in which an operator has multiple LAA base station and each base station has one UE attached to it. The base stations are close to each other (e.g. d2=10).
I was expecting to see that an eNB starts transmitting when it estimates the channel as idle after the txop of another LAA.
From the results and printings on the screen I am seeing that an eNB potentially starts transmitting even during the txop of another eNB. It seems that the CCA mechanism is not triggered between the eNBs of the same operator.
Is this a known issue?
Normally eNBs of the same operator should backoff during the txop of another eNB right?
Thank you very much.
Best regards,
Vasilis
Vasilis
Apr 19, 2017, 12:14:30 PM4/19/17
to ns-3-users
I forgot to mention that I am sending continuous UDP traffic from each BS to the attached UE
Tom Henderson
Apr 19, 2017, 3:00:40 PM4/19/17
to ns-3-...@googlegroups.com
another, have you checked this?
- Tom
Vasilis
Apr 20, 2017, 4:43:40 AM4/20/17
to ns-3-users
Hello Tom,
Thank you for the reply.
Thank you for the reply.
Yes I have checked that. I have changed the ED threshold to several values but the result is the same.
Actually I have noticed that I get this effect only if I have 3 or more LAA BS at the same operator in the proximity of each other. When I have 2 BS then they backoff during the txop of each other.
The BS<->UE of the other Operator are placed far away from the Operator under-test so they don't affect the results.
I have tried different placements of the BS with the same results.
e.g.
bsNodesA.Create (1);
bsNodesB.Create (3);
ueNodesA.Create (1);
ueNodesB.Create (3);
positionAlloc->Add (Vector (1000, 0.0, 0.0)); // eNB0 in cell 0. Far from OperatorB
positionAlloc->Add (Vector (0, 0.0, 0.0)); // eNB1 in cell 1
positionAlloc->Add (Vector (8, 0.0, 0.0)); // eNB2 in cell 2
positionAlloc->Add (Vector (16, 0.0, 0.0)); // eNB3 in cell 3
positionAlloc->Add (Vector (1000, 10, 0.0)); // UE0 in cell 0. Far from OperatorB
positionAlloc->Add (Vector (0, 5, 0.0)); // UE1 in cell 1
positionAlloc->Add (Vector (8, 5, 0.0)); // UE2 in cell 2
positionAlloc->Add (Vector (16, 5, 0.0)); // UE3 in cell 3Any help will be much appreciated!
Vasilis
Zoraze Ali
Apr 21, 2017, 6:05:12 AM4/21/17
to ns-3-users
Hi Vasilis,
Could you please check if the voice application is enabled in your scenario? If yes, try to disable it or randomize its start time for both of the UEs of eNB 1 and eNB2.
Kind regards,
Zoraze
Could you please check if the voice application is enabled in your scenario? If yes, try to disable it or randomize its start time for both of the UEs of eNB 1 and eNB2.
Kind regards,
Zoraze
Biljana Bojovic
Apr 21, 2017, 6:29:08 AM4/21/17
to ns-3-...@googlegroups.com
Hi Vasilis,
can you please attach back-off log file (.zip) ?--
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.
Vasilis
Apr 21, 2017, 8:37:54 AM4/21/17
to ns-3-users
Dear all,
Thank you all for your answers.
The last days I tried to debug the issue that I mentioned and I think I have found what possibly is wrong.
On my last answer I said that I notice this issue for more than 3 LAA BS of the same operator next to each other. This was wrong. This issue can occur also for 2 LAA BS of the same operator next to each other or even for 2 LAA BS of different operators next to each other.
I believe that this issue arrises from the way that the CCA procedure is implemented. When a LAA BS wants to transmit, it senses the channel for a defer period and a backoff period. If the channel is idle, it decreases the backoff counter and if it is busy it freezes the counter.
When the counter reaches 0 and the channel is idle then it transmits. But in our case, this can happen even during the txop of another BS.
When the counter reaches 0 and the channel is idle then it transmits. But in our case, this can happen even during the txop of another BS.
I have noticed two scenarios that this can happen:
- An LAA BS stops transmitting when the next subframe will surpass the txop length and asks for a new grant. In this case, the neighboring BSs will try to access the medium. If both BS have m_backoffCount = 0 then they start transmitting simultaneously.
- I noticed that during a txop a BS (let's name it A) can delay some times to transmit between consecutive subframes (e.g. delay of 785 us). In this case another neighboring BS (let's name it B) can gain access to the channel and start transmitting (in the beginning a reservation signal and then to continue with its txop). Then, the A continues sending during its txop and as a result A and B send simultaneously (until the end of the txop of LAA BS A). This can be seen in the following output where eNB 3 is transmitting and then during its txop eNB2 gains access to the channel
0xfb7590 eNB: 3 LTE DATA frame at +4115214286.0ns with duration: +785713.0ns UNTIL +4115999999.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4115214286.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4115214286.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4115214286.0ns
3 RX LTE DATA frame at +4115214286.0ns with duration: +785713.0ns UNTIL +4115999999.0ns
*********************************************************************
0xfb7590 eNB: 3 LTE CTRL frame at +4116000000.0ns with duration: +214285.0ns UNTIL +4116214285.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4116000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4116000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4116000000.0ns
3 RX LTE CTRL frame at +4116000000.0ns with duration: +214285.0ns UNTIL +4116214285.0ns
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Defer succeeded, scheduling for 576 backoffSlots
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Defer succeeded, scheduling for 9 backoffSlots
eNB: 2 start tx reserv signal at:4116 until:+4117000000.0ns
0xfae500 eNB: 2+++++++LTE DATA frame at +4116338285.0ns with duration: +661714.0ns UNTIL +4116999999.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +661714.0ns at time +4116338285.0ns
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 575
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 574
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 573
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 572
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 571
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 570
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 569
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 568
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Current backoff count 567
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Suspend backoff, go busy until 4116999
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +661714.0ns at time +4116338285.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +661714.0ns at time +4116338285.0ns
0xfc6b00 eNB: 3+++++++LTE DATA frame at +4117000000.0ns with duration: +928570.0ns UNTIL +4117928570.0ns
*********************************************************************
0xfae500 eNB: 2+++++++LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0ns
*********************************************************************
0xfb7590 eNB: 3+++++++LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
0xfc3660 eNB: 2==========RX LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
0xfc64c0 eNB: 3==========RX LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0nsA part of the problem in (2) is that the CCA procedure does not take into consideration the potentially ongoing txop from other BS. I have defined a
Vasilis
Apr 21, 2017, 9:00:12 AM4/21/17
to ns-3-users
Dear all,
Sorry for double posting, the previous answer was posted by accident unfinished.
Sorry for double posting, the previous answer was posted by accident unfinished.
Thank you all for your answers.
@Zoraze: No I am not using any voice application.
2==========RX LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
--------------------------------------------------------------------------------------Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4117000000.0ns
3==========RX LTE CTRL frame at +4117000000.0ns with duration: +214285.0ns UNTIL +4117214285.0ns
A part of the problem in (2) is that the CCA procedure does not take into consideration the potentially ongoing txop from other BS.
Am I missing something here? Are my assumptions correct?
Best regards,
In order to solve the problem I use a global variable to store the latest start of a txop. Then in the RequestAccessAfterDefer function, I compare the Simulator::Now() value with the (latest start of txop + the duration of txop).
If the Simulator::Now() value is bigger then I proceed otherwise I defer again.
If you have any other proposals to solve this bug I am very willing to discuss.
Best regards,
Vasilis
Zoraze Ali
Apr 21, 2017, 9:22:10 AM4/21/17
to ns-3-users
Hi Vasilis,
I understood your first point and i can reproduce it. However, i am not sure about the second one. Could you please tell the start time of any two TXOPs which are overlapping?
Kind regards,
Zoraze
I understood your first point and i can reproduce it. However, i am not sure about the second one. Could you please tell the start time of any two TXOPs which are overlapping?
Kind regards,
Zoraze
Vasilis
Apr 21, 2017, 10:46:05 AM4/21/17
to ns-3-users
Hi Zoraze, all,
Regarding the second point:
Below you can find 2 examples that highlight my two points.
Regarding the first point:
eNB: 1 LTE DATA frame at +4611214286.0ns with duration: +785713.0ns UNTIL +4611999999.0ns // eNB 1 transmits during its txop
Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4611214286.0ns
Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4611214286.0ns
Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4611214286.0ns
1 RX LTE DATA frame at +4611214286.0ns with duration: +785713.0ns UNTIL +4611999999.0ns
eNB: 1 LTE DATA frame at +4612000000.0ns with duration: +928570.0ns UNTIL +4612928570.0ns // The next TX will surpass the txop so it is not transmitted
Defer succeeded, scheduling for 3 backoffSlots @ +4612033999.0ns
Defer succeeded, scheduling for 3 backoffSlots @ +4612033999.0ns
Defer succeeded, scheduling for 10 backoffSlots @ +4612033999.0ns
eNB: 2 ************************************************************************ start tx reserv signal at:4612 until:+4613000000.0ns // eNB2 transmits a reservation signal
eNB: 2 LTE DATA frame at +4612060999.0ns with duration: +939000.0ns UNTIL +4612999999.0ns
eNB: 3 ************************************************************************ start tx reserv signal at:4612 until:+4613000000.0ns // eNB3 transmits a reservation signal
eNB: 3 LTE DATA frame at +4612060999.0ns with duration: +939000.0ns UNTIL +4612999999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
Calling SwitchMaybeToCcaBusy for +939000.0ns at time +4612060999.0ns
eNB: 1 LTE DATA frame at +4613000000.0ns with duration: +928570.0ns UNTIL +4613928570.0ns // the TX of eNB1 is dropped or ignored
eNB: 2 LTE CTRL frame at +4613000000.0ns with duration: +214285.0ns UNTIL +4613214285.0ns // eNB2 transmits
eNB: 3 LTE CTRL frame at +4613000000.0ns with duration: +214285.0ns UNTIL +4613214285.0ns // eNB3 transmits
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
2 RX LTE CTRL frame at +4613000000.0ns with duration: +214285.0ns UNTIL +4613214285.0ns
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4613000000.0ns
3 RX LTE CTRL frame at +4613000000.0ns with duration: +214285.0ns UNTIL +4613214285.0nseNB: 1 ************************************************************************ start tx reserv signal at:4620 until:+4621000000.0ns // Start of TX by eNB1. The txop = 8 ms expected to end at 4628eNB: 1 LTE DATA frame at +4620096999.0ns with duration: +903000.0ns UNTIL +4620999999.0nsCalling SwitchMaybeToCcaBusy for +903000.0ns at time +4620096999.0nsCalling SwitchMaybeToCcaBusy for +903000.0ns at time +4620096999.0nsCalling SwitchMaybeToCcaBusy for +903000.0ns at time +4620096999.0nseNB: 2 LTE DATA frame at +4621000000.0ns with duration: +928570.0ns UNTIL +4621928570.0nseNB: 3 LTE DATA frame at +4621000000.0ns with duration: +928570.0ns UNTIL +4621928570.0ns
eNB: 1 LTE CTRL frame at +4621000000.0ns with duration: +214285.0ns UNTIL +4621214285.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4621000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4621000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4621000000.0ns 1 RX LTE CTRL frame at +4621000000.0ns with duration: +214285.0ns UNTIL +4621214285.0ns //UE1 RXeNB: 1 LTE DATA frame at +4621214286.0ns with duration: +785713.0ns UNTIL +4621999999.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4621214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4621214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4621214286.0ns 1 RX LTE DATA frame at +4621214286.0ns with duration: +785713.0ns UNTIL +4621999999.0ns //UE1 RXeNB: 2 LTE DATA frame at +4622000000.0ns with duration: +928570.0ns UNTIL +4622928570.0nseNB: 3 LTE DATA frame at +4622000000.0ns with duration: +928570.0ns UNTIL +4622928570.0ns
eNB: 1 LTE CTRL frame at +4622000000.0ns with duration: +214285.0ns UNTIL +4622214285.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4622000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4622000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4622000000.0ns 1 RX LTE CTRL frame at +4622000000.0ns with duration: +214285.0ns UNTIL +4622214285.0ns //UE1 RXeNB: 1 LTE DATA frame at +4622214286.0ns with duration: +785713.0ns UNTIL +4622999999.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4622214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4622214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4622214286.0ns 1 RX LTE DATA frame at +4622214286.0ns with duration: +785713.0ns UNTIL +4622999999.0ns //UE1 RXeNB: 2 LTE DATA frame at +4623000000.0ns with duration: +928570.0ns UNTIL +4623928570.0nseNB: 3 LTE DATA frame at +4623000000.0ns with duration: +928570.0ns UNTIL +4623928570.0ns
eNB: 1 LTE CTRL frame at +4623000000.0ns with duration: +214285.0ns UNTIL +4623214285.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4623000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4623000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4623000000.0ns 1 RX LTE CTRL frame at +4623000000.0ns with duration: +214285.0ns UNTIL +4623214285.0ns //UE1 RXeNB: 1 LTE DATA frame at +4623214286.0ns with duration: +785713.0ns UNTIL +4623999999.0ns //eNB 1 TXCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4623214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4623214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4623214286.0ns 1 RX LTE DATA frame at +4623214286.0ns with duration: +785713.0ns UNTIL +4623999999.0ns //UE1 RX eNB: 1 LTE CTRL frame at +4624000000.0ns with duration: +214285.0ns UNTIL +4624214285.0ns Calling SwitchMaybeToCcaBusy for +214285.0ns at time +4624000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4624000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4624000000.0ns 1 RX LTE CTRL frame at +4624000000.0ns with duration: +214285.0ns UNTIL +4624214285.0ns eNB: 1 LTE DATA frame at +4624214286.0ns with duration: +785713.0ns UNTIL +4624999999.0ns Calling SwitchMaybeToCcaBusy for +785713.0ns at time +4624214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4624214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4624214286.0ns 1 RX LTE DATA frame at +4624214286.0ns with duration: +785713.0ns UNTIL +4624999999.0nseNB: 1 LTE DATA frame at +4625000000.0ns with duration: +928570.0ns UNTIL +4625928570.0ns eNB: 1 LTE CTRL frame at +4625000000.0ns with duration: +214285.0ns UNTIL +4625214285.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4625000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4625000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4625000000.0ns 1 RX LTE CTRL frame at +4625000000.0ns with duration: +214285.0ns UNTIL +4625214285.0nseNB: 1 LTE DATA frame at +4625214286.0ns with duration: +785713.0ns UNTIL +4625999999.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4625214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4625214286.0nsCalling SwitchMaybeToCcaBusy for +785713.0ns at time +4625214286.0ns 1 RX LTE DATA frame at +4625214286.0ns with duration: +785713.0ns UNTIL +4625999999.0nseNB: 1 LTE DATA frame at +4626000000.0ns with duration: +928570.0ns UNTIL +4626928570.0ns eNB: 1 LTE CTRL frame at +4626000000.0ns with duration: +214285.0ns UNTIL +4626214285.0ns $$$$$$$$$$$$$$$$$$$ CW reset from 15 to 15 @ +4626000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4626000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4626000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4626000000.0nseNB: 1 RX LTE CTRL frame at +4626000000.0ns with duration: +214285.0ns UNTIL +4626214285.0ns
Defer succeeded, scheduling for 46 backoffSlots @ +4626248285.0nsDefer succeeded, scheduling for 22 backoffSlots @ +4626248285.0ns
eNB: 3 ************************************************************************ start tx reserv signal at:4626 until:+4627000000.0ns // Reservation signal by eNB 3 at 4626
eNB: 3 LTE DATA frame at +4626446285.0ns with duration: +553714.0ns UNTIL +4626999999.0nsCalling SwitchMaybeToCcaBusy for +553714.0ns at time +4626446285.0nsCalling SwitchMaybeToCcaBusy for +553714.0ns at time +4626446285.0nsCalling SwitchMaybeToCcaBusy for +553714.0ns at time +4626446285.0nseNB: 1 LTE DATA frame at +4627000000.0ns with duration: +928570.0ns UNTIL +4627928570.0ns
eNB: 1 LTE CTRL frame at +4627000000.0ns with duration: +214285.0ns UNTIL +4627214285.0ns //eNB 1 TX (continues its txop)
eNB: 3 LTE CTRL frame at +4627000000.0ns with duration: +214285.0ns UNTIL +4627214285.0ns //eNB 3 TXCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0ns 1 RX LTE CTRL frame at +4627000000.0ns with duration: +214285.0ns UNTIL +4627214285.0ns //UE1 RXCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0nsCalling SwitchMaybeToCcaBusy for +214285.0ns at time +4627000000.0ns 3 RX LTE CTRL frame at +4627000000.0ns with duration: +214285.0ns UNTIL +4627214285.0ns //UE3 RXFor this scenario I use:
RngRun=20
RngRun=20
TX duration of 10 s
TXOP=8
operatorA Wifi
operatorB Laa
type of traffic: UDP
LAA ED threshold -82 (just to make sure that I am always above the threshold)
And the position is:
bsNodesA.Create (1);
bsNodesB.Create (3);
ueNodesA.Create (1);
ueNodesB.Create (3);
allWirelessNodes = NodeContainer (bsNodesA, bsNodesB, ueNodesA, ueNodesB);
positionAlloc->Add (Vector (1000.0, 0.0, 0.0)); // AP0 in cell 0 far from operator B
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 far from operator B
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 3I hope it is more clear now :)
Best regards,
Vasilis
Zoraze Ali
Apr 21, 2017, 11:36:42 AM4/21/17
to ns-3-users
Hi Vasilis,
Thanks for the details, but you forgot to mention the values of d1 and d2. Actually, I want to reproduce the same behavior at my end so every info related to the simulation parameters matters. And, just to be sure you, are you using the ns-3-lbt repo available here http://code.nsnam.org/laa/ns-3-lbt/ ?
Kind regards,
Zoraze
Thanks for the details, but you forgot to mention the values of d1 and d2. Actually, I want to reproduce the same behavior at my end so every info related to the simulation parameters matters. And, just to be sure you, are you using the ns-3-lbt repo available here http://code.nsnam.org/laa/ns-3-lbt/ ?
Kind regards,
Zoraze
Vasilis
Apr 21, 2017, 12:40:44 PM4/21/17
to ns-3-users
Hi Zoraze,
Indeed, this is the release I am using (phase 3).
Sorry for the omission. The complete list of the configuration parameters is as follows:
RngRun: 20
transport type: Udp
Simulation duration (seconds): 10
voiceEnabled: 0
wifiQueueMaxSize: 2000 it doesn't matter for the current issue
laaTxMode: 2 (LAA MIMO)
d1: 10
d2: 10
useReservationSignal: true
LAA ED threshold: -82.0
ChannelAccessManager: Lbt
MinCw: 15
MaxCw: 1023 (or 63) it doesn't really matter as it rarely increases
deferTime: 34 (or 43) also it doesn't make a difference as far as I have seen
I hope those are OK to reproduce the scenarios.
For any further information, please let me know.
Best regards,
Vasilis
Zoraze Ali
Apr 23, 2017, 6:55:56 PM4/23/17
to ns-3-users
Hi Vasilis,
Sorry for bit delayed reply. Could you please log Phy arrivals with node 1 or node 3 by configuring the parameters: logPhyArrivals=1 --logPhyNodeId=1? In the logs you could see at what level the nodes sense each other. I assume they sense each other below ED threshold. Additionally, why you set the position of eNB 2 to (0.0, 0.0, d2) ? This might also impact the calculation of propagation loss model.
Kind regards.
Zoraze
Sorry for bit delayed reply. Could you please log Phy arrivals with node 1 or node 3 by configuring the parameters: logPhyArrivals=1 --logPhyNodeId=1? In the logs you could see at what level the nodes sense each other. I assume they sense each other below ED threshold. Additionally, why you set the position of eNB 2 to (0.0, 0.0, d2) ? This might also impact the calculation of propagation loss model.
Kind regards.
Zoraze
Vasilis
Apr 24, 2017, 4:19:16 AM4/24/17
to ns-3-users
Hi Zoraze,
Thank you for your reply.
Firstly, regarding the position, I am not sure if this could cause a problem as it indicates the position of the node in a 3D space.
However, I run again the experiment with the following positions:
positionAlloc->Add (Vector (1000.0, 0.0, 0.0)); // AP0 in cell 0 far from cell B
positionAlloc->Add (Vector (10, 0.0, 0.0)); // eNB1 in cell 1
positionAlloc->Add (Vector (15, 0.0, 0.0)); // eNB2 in cell 2
positionAlloc->Add (Vector (20, 0.0, 0.0)); // eNB3 in cell 3
positionAlloc->Add (Vector (1000.0, 4, 0.0)); // STA0 in cell 0 far from cell B
positionAlloc->Add (Vector (10, 4, 0.0)); // UE1 in cell 1
positionAlloc->Add (Vector (15, 4, 0.0)); // UE2 in cell 2
positionAlloc->Add (Vector (20, 4, 0.0)); // UE3 in cell 3Attached you can find the phy_log and harq_feedback_log files.
From the phy_log files you can see that there are several instances during which LAA eNB nodes transmit simultaneously (the one during the txop of the other).
The configuration parameters are the same and the TXOP is again 8ms and the ED threshold is again set to -82.
The configuration parameters are the same and the TXOP is again 8ms and the ED threshold is again set to -82.
For example:
#time(s) nodeId type sender endTime(s) duration(ms) powerDbm
4.794042999 1 lte 3 4.794999999 0.957000000 -53.677700000 //reservation signal from eNB3
4.795000000 1 lte 3 4.795214285 0.214285000 -53.677700000
4.795214286 1 lte 3 4.795999999 0.785713000 -53.677700000
4.796000000 1 lte 3 4.796214285 0.214285000 -53.677700000
4.796214286 1 lte 3 4.796999999 0.785713000 -53.677700000
4.797000000 1 lte 3 4.797214285 0.214285000 -53.677700000
4.797365285 1 lte 2 4.797999999 0.634714000 -44.646800130 //reservation signal from eNB2
4.798000000 1 lte 2 4.798214285 0.214285000 -44.646800130
4.798000000 1 lte 3 4.798214285 0.214285000 -53.677700000
4.798214286 1 lte 2 4.798999999 0.785713000 -44.646800130
4.798214286 1 lte 3 4.798999999 0.785713000 -53.677700000
4.799000000 1 lte 2 4.799214285 0.214285000 -44.646800130
4.799000000 1 lte 3 4.799214285 0.214285000 -53.677700000
4.799214286 1 lte 2 4.799999999 0.785713000 -44.646800130
4.800000000 1 lte 2 4.800214285 0.214285000 -44.646800130
4.800000000 1 lte 3 4.800214285 0.214285000 -53.677700000Were you able already to reproduce the results?
I think that the problem occurs by the fact that the LBT mechanism does not take into account the end of the duration of an TXOP.
Of course a node stops transmitting after the end of its TXOP until a new TXOP is granted. But during the TXOP another node can start transmitting when its CCA succeeds. This results to the above described behaviour.
Best regards,
Vasilis
Zoraze Ali
Apr 24, 2017, 11:38:11 AM4/24/17
to ns-3-users
Hi Vasilis,
I am able to reproduce the behavior you reported and have filed a bug report. Following is the link to the bug report.
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2730
From the logs it seems the problem always arises when a node transmits only a CTRL signal during the whole subframe duration of 1 msec. Therefore, the other node finds the channel free after
Kind regards,
Zoraze
I am able to reproduce the behavior you reported and have filed a bug report. Following is the link to the bug report.
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2730
From the logs it seems the problem always arises when a node transmits only a CTRL signal during the whole subframe duration of 1 msec. Therefore, the other node finds the channel free after
~0.214 ms and starts transmiiting reservation signal, e.g., row 6 and 7 of the logs you reported in your previous reply. So, i think the key point here is to track the reason of this only CTRL transmission. Kind regards,
Zoraze
Vasilis
Apr 26, 2017, 4:04:24 AM4/26/17
to ns-3-users
Hi Zoraze,
Many thanks for this! Indeed you are right.
Moreover, if a WiFi node is in the proximity of the LAA that does not send DATA after CTRL then it potentially (if backoff counter reaches 0) exploits this gap to start a transmission.
Best regards,
Vasilis
Reply all
Reply to author
Forward
0 new messages